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The  overail  objective  of  the  IJepartment  of  Defense  Computer-aided 
Acquisition  &  Logistic  Support  ;CALS)  Trogram  is  to  inre-rate  the 
design,  manufacturing,  and  logistic  functions  through  the 
efficient  application  of  computer  technology.  CALS  is  a  program 
to  apply  existing  and  emerging  communications  and  computer-aided 
technologies  in  DoD  and  :.ndustr\*  to : 

o  Integrate  and  improve  design,  manufacturing,  and 

logistic  functions;  thereby  bridging  existing  "islands 
of  automation." 

o  Actively  influence  the  design  process  to  produce  weapon 
systems  that  are  more  reliable  and  easier  to  support 
anc.  maintain. 

o  Shift  from  current  paper- intensive  weapon  support 

processes  to  a  highly  autc-ated  mode  of  operation, 
based  on  a  unified  DoD  interface  with  industry  for 

exchange  of  logistic  technical  information  in  digital 
form. 

The  CALS  program  was  estadslished  by  the  Deputy  Secretary  of 

Defense  in  September  1985  to  implement  the  recommendations  of  a 
Joint  Industry/DoD  Task  Force.  Management  is  provided  by  a  DoD 
Steering  Group,  an  OSD  CALS  Policy  Office,  and  their  counterparts 
in  each  Military  Department  and  the  Defense  Logistics  Agency. 
The  CALS  Policy  Office  has  obtained  the  support  of  the  National 
Bureau  of  Standards  in  the  selection  and  implementation  of  C.-.LS 
standards.  An  Industry  Steering  Group  has  also  been  established 
to  focus  the  work  of  key  industrial  associations  and  the  defense 
contractor  community  in  CALS  implementation. 

The  Bureau  has  been  funded  since  Spring  1986  to  recommend  a  suite 
of  industry  standards  for  system  integration  and  digital  data 
transfer,  and  to  accelerate  their  implementation.  NBS  activities 
duri.ng  1936  were  primarily  aimed  at; 

o  familiaricing  NBS  technical  staff  with  key  DoD  logistic 
functions  and  CALS  demonstration  projects, 

o  briefing  DoD  personnel,  contractors,  and  other 

interested  parties  on  Federal,  national,  arc 
international  standardization  efforts  that  an  expected 
to  support  CALS  objectives, 

o  identifying  a  preliminary’’  set  of  standards  required  for 
data  interchange  in  support  of  CALS,  and 

o  developing  reports  on  the  four  broad  categories  of 
standards  required  to  support  the  interchange  cf  CALS 
digitized  technical  information;  (1)  product  definition 
data,  (2)  graphics,  (3)  text,  and  (4)  data  management. 

As  a  result  of  these  efforts,  NE3  made  a  preli.c.inary 
identification  of  several  high-priority  suandards  implemenrations 


needed  for  CALS  data  interchange  ar.d  access.^  Building  on 
knowledge  and  experience  gained  during  FV86,  NBS  fo-used  on  the 
following  activi'-ies  in  FY87;  developing  a  CALS  Framework, 
Develr,  mer  r  Plan  and  Core  Requirements  Package;  providing 
technical  support  fcr  standards  development  and  implementation; 
a “5  conducting  workshors  and  meetir.gs  uo  promote  dialogue  with 
hht  Services,  the  Defense  Logistics  Agency,  and  industry. 

A  major  FY87  hhrust  was  the  completion  of  initial  documentation 
of  the  high-priority  standards  required  in  the  CALS  environment. 
Some  of  these  standards  (e.c.,  SGML,  IGES)  required  tailoring  or 
enhancement.  Other  standards  required  a  "push”  (e.g.,  CGEM)  for 
their  development  in  a  timely  lushion.  These  four  volumes  are  a 
collection  of  the  final  reports  presented  to  the  CALS  Policy 
Office. 2  The  collection  is  divided  as  follows: 

VOLDME  1: 

Text 

Evaluation  of  Text  Interchange  Methods 

Plan  for  Conformance  Testing  for  DoD  Implementation  of  SGML 

Guidelines  for  the  Development  of  Tags  for  SGML 

The  NBS  FIPS  -  SGML  Validation  Suite 

The  NBS  FIPS  -  SGML  Reference  Parser 

Using  SGML  -  Application  Guidelines 

ODA/ODIF  Implementation  Agreement  a  Document  Application 
Profile 

Data  -Management 

CALS  Report  on  Data  Management  Standards 

Supporting  Logistic  Support  Analysis  (LSA)  Using  the 
Information  Resource  Dictionary  System  (IRDS) 


Media 

ICST  Recommendations  on  Optical  Disks  and  Interface 
Req-uirements  for  Planned  EDMICS  Procurement,  Final 
Report 


Kemmerer,  S.,  Editor,  "Final  NBS  Report  fcr  C.hLS, 
FY86,"  U.S.  Department  of  Commerce,  National  Bureau  of 
Standards,  NBSIR  87-?566,  May  1967. 

The  publishing  of  this  collection  of  reports  does  not 
imply  the  CALS  Policy  Office  has  endorsed  the 
conclusions  and  recommendations  presented. 
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Raster  Compresr  lor. 

Report  on  Raster  Graphics 

Tiled  Raster  Interchange  Format,  TRIP  Version  1.0,  Rev.  1.2 
Conformance  Testing 

NFS  Plan  for  Validation  (Conformance  Testing)  of  Computer 
Products  in  Support  of  the  CALS  Program 

VOLUME  2: 

Graphics 

Raster-to-Vectcr  Conversion:  A  State-of-the-Art  Assessment 
Development  of  CGM  Validation  Routines 
CALS  Application  Profile  for  CGM 

CALS  Requirements  Reflected  in  the  Extended  CGM  (CGEM) 
Standards  Effort 

A  Reference  Implementation  for  CGM,  Functional  Requirements 
and  Conceptual  Design 

IGES  to  CGM  Translator  Design  Specification 

VOLOME  3: 

Graphics 

CGM  Registration  For  CALS  Requirements 

VOLUME  4: 

Product  Data 

Guidelines  for  Testing  IGES  Translators 
Guidelines  -  for  IGES  Application  Subsets 


iii 


The  followirr  are  additional  deliverables  conpleted  by  r  BS  during 
FY87  but  under  separate  cover.  They  are  availzdale  through  the 
CALS  Policy  Office. 

CALS  Core  Requirements,  Phase  I.O 

Ci.LS  Framework' 

CALS  Program  Integration  of  Logistic  Support  Analysis  and 
Reliability  and  Maintainability  Data  Deliverables 

CALS  Current  State  of  Digital  Technology  (Phase  I.O) 

CALS  Workshop  Proceedings: 

Graphics  Data  Interface  for  Engineering  Design  and  Technical 
Publication  Systems  (January  13/14) 

Introduction  to  the  Core  Requirements  Package  (April  23) 

KILSTD-1840A,  Automated  Ir.tercnange  of  Technical  Information 

MILSPEC-D-28000,  Digital  Representation  for  Communication  of 
Product  Data:  Application  Subsets 

MI1-SPEC-M-2  8  0C1 ,  Manuals,  Techrlccl:  Markup  Requirements  and 

G;.  ceric  Style  Specification  for  Electronic  Printed  Output 
and  Exchange 
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1.  Tngrodugtlon:  This  report  presents  results  from  the  r:  87  project  c- 
digital  product  data  undertaken  by  c  e  Engineering  CAD/CAK  Group  at  the 
National  Bureau  of  Standards  (NBS).  The  work  was  sponsored  by  the 
Department  of  Defense  program  on  Computer  £.._sd  Acquiriticn  and  ristics 
(iALS)  and  concerns  the  development  of  methods  for  testing  t;  u  qua. ; ty 
and  completeness  of  Computer  aided  Design  CAD)  data  e:. mange  throur-  the 
Initial  Graphics  Exchange  Specification  v  .£S). 

CALS  resources  were  used  to  augment  and  a.celerate  the  KBS 'led.  voluntar; 
IGES/PDES  Organization  involving  over  600  experts  from  260  companies . 

The  goal  of  the  FY  £7  CALS  sponsored  program  was  to  establish  a  National 
Testing  Program  for  IGES  translators.  The  CALS  funding  produced 
significant  deliverables  in  the  development  of  testing  methodology  for 
IGES  translators  and  in  the  development  of  the  IGES  application  sunset 
concept  and  its  incorporation  into  a  formal  military  specification  for 
procurement  of  datasets. 

The  testing  methodology  being  developed  by  the  IGES/PDES  rrganization 
committees  recognizes  three  inter-related  levels  of  translator  testing: 

Verification  Testing  -  The  testing  of  vendor  claims  and  conformance 

of  IGES  translators  to  the  IGES  Specification 
through  individual  entity  tests. 

Application  Testing  -  The  testing  of  functionality  in 

specific  application  areas  through  entity- 
entity  and  entity-attribute  interactions . 

Acceptance  Testing  -  User  testing  that  assesses  t'  degree 

of  compatibility  of  different  C.A.D/CAM  systems 
in  the  users'  shop  and  operational 
environment . 

The  CALS  objective  in  the  verification  task  is  to  estabil.sh  a  National 
Translator  Testing  Program  under  the  direction  of  the  Society  of 
•Automotive  Engineers  (SAE).  Necessary  cenditierr  for  t-is  include  the 
existence  of  comprehensive  testing  procedures  approved  “■  the  IGES/PDF.S 
Organization,  the  training  of  knowledgeable  test  teams,  and  the 
development  of  well  documented  test  cases.  The  first  was  developed  .■>y 
NES  under  the  CALS  program  and  is  reported  here  as  the  "Quickstart" 
program.  This  effort,  presented  in  June  1987,  integrated  divergent  views 
in  several  IGES  Committees  and  moved  the  organization  cowards  consensus. 
The  approach  was  next  refined  and  extensively  tested  under  the  name  of 
tr-.  "Ouickstart  Jr"  program.  The  methodology  is  presently  viewed  as 
fi;  i.ehed  and  ready  for  use  by  the  SA.Z  in  tne  trial  phase  testing  program. 

The  verification  methodology  was  thoroughly  tested  in  the  "Ouirkst...rt  jr" 
program  against  four  CAD  systems.  Presentations  of  the  mechr  oolog;.-  to 
the  various  testing  committees  and  outside  observers  resulted  in 
im.r  rovements  to  the  test  scheme  and  its  imp  iem.er.tation.  During  a  live 
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demonstration  of  the  verification  two  test  incidents  were  encountered 
that  caused  an  error  report  to  be  sent  to  one  vendor. 


1.1.  Background :  To  the  greatest  extent  possible,  this  document 
represents  both  the  philosophy  and  intent  of  the  ICES  Organization  and 
the  NBS  Center  for  Manufacturing  Engineering.  Readers  are  reminded  chat 
future  progress  in  the  implementation  of  the  methodology  as  well  as 
mutual  development  with  the  International  Standards  Organization 
committee  TC  184/SC4  testing  effort  make  the  material  herein  subject  to 
change  and  refinement. 

The  work  has  benefited  from  the  collective  experience  in  ICES  testing 
developed  at  companies  participating  in  the  voluntary  effort.  Three 
important  contributors  were;  1)  the  Department  of  Energy  DOEDEF  project, 
2)  the  General  Motors  Testing  Program,  and  3)  the  British  effort  at  the 
University  of  Leeds.  Active  discussions  with  representatives  of  these 
projects  continue  to  identify  and  incorporate  the  best  features  of  each 
program. 


In  1986  the  ICES  Testing  Committee  determined  that  in  order  to  achieve 
its  mission  goals  in  a  reasonable  time  frame,  it  needed  to  reorganize 
into  six  separate  IGES  committees: 

0  Verification  Testing  Committee 
o  Application  Validation  Testing  Committee 
o  Acceptance  Testing  Committee 
0  Test  Case  Committee 
o  Methodology  Testing  Committee 
o  User  Information  Committee 

These  six  committees  now  comprise  a  formal  IGES  testing  project.  This 
gives  the  IGES  organization  four  projects  1.-  IGES,  2.-PDES,  3.-  Testing 
.Methodology,  and  4.-  ISO  activities. 

NBS  is  working  intensively  with  the  committees  in  an  effort  to  accelerate 
the  development  of  the  methodologies  and  initiate  a  National  IGES 
Translator  Testing  Program  under  the  control  of  the  Society  of  Automotive 
Engineers . 

Other  work  of  the  Testing  Methodology  Project  includes  or  will  include 
the  IGES  Version  4.0  and  5.0  entities  into  the  Verification  Testing 
program,  development  of  Application  Testing  Programs,  generation  of 
Acceptance  Testing  Guidelines,  and  PDES  testing. 


1.2.  Status :  Verification  testing  requires  both  a  methodology  for 
performing  the  test  and  test  cases  to  be  used  for  specific  CAD  systems. 
While  developing  and  validating  the  methodology  is  a  manageable  task,  the 
development  of  test  cases  for  all  possible  entities,  form  numbers  and 
attributes  would  require  years  of  concentrated  work.  Clearly,  this  is 


3 


unacceptable  for  DOD,  NBS,  and  the  ICES  comaunlty.  To  avoid  this 
proc^em,  the  NBS  IGES  office  developed  a  plan  to  put  in  place  a 
simplified  National  Testing  Program  during  the  first  quarter  of  1988. 

This  plan,  called  "Quickstart" ,  is  complete  in  terms  of  the  methodology 
and  procedures,  and  makes  use  of  a  subset  of  test  cases  capable  of 
£.;rportinr  CAD  systems  and  application  st  sets  in  typical  use  today. 

The  "Quickstart"  approach  was  designed  to  verify  chose  IGES  entities 
selected  from  the  proposed  DOD  application  subsets  (Technical  Publication 
Illuscrations ,  Engineering  Drawings  and  Eleccrical/Electronic 
Applications).  The  effort  developed  anc  used  the  same  testing  procedures 
chat  will  be  used  by  Che  Society  of  Automotive  Engineers.  This  aliov--d 
tpp.  testing  effort  to  "shake  out"  the  system  with  a  rt  duced  1  ad  of 
entities  and  readily  achievable  goals. 

The  "Quickstart  jr."  approach  was  initiated  in  July  with  Che  ir.rent  to 
produce  the  detailed  procedures  required  by  the  Society  of  Automotive 
Engineers,  (SAE) ,  and  their  testing  agencies.  To  accomplish  this,  five 
IGES  test  cases,  a  set  of  foirmal  preprocessor  and  postprocessor  test 
procedures,  four  sepurate  CAD  systems  and  different  CAD  users  were  used 
to  define  and  develop  the  testing  process.  The  results  of  this  work  are 
aiscussed  at  length  in  this  document. 

Future  testing  activities  will  concentrate  on  developing  and  document .ng 
the  complete  sec  of  test  cases  needed  by  the  SAE.  Attempts  will  al. '  be 
made  to  reconcile  and  utilize  the  efforts  from  DOEDEF,  General  Motor.*- 
and  Che  University  of  Leeds.  The  testing  program  at  the  Univers-.ty  c: 
Leeds  is  of  particular  importance  because  of  their  established  base  of 
testing  tools  and  testing  experience. 

.■additional  efforts  will  be  aimed  at  initiating  Che  SAE  testing  program 
stabilizing  the  testing  procedures,  generating  test  cases  for  IGi-S 
Version  4.0  entities,  acquiring  testing  cools,  and  designing  an 
information  system  for  manipulating  the  test  results. 
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2.  A  Reference  Model  for  CAD-Based  Data  Exchange:  When  dealing  with  the 
issues  of  data  exchange,  It  is  usually  beneficial  to  define  a  universe  of 
discourse  in  order  to  establish  a  conusor  frame  of  reference.  To  that 
end,  the  reference  model  shown  in  Figure  1  was  created.  The  model  was 
designed  in  the  context  of  current  ICES  usage.  That  is,  knowledg< able 
human  intein.'ention  is  a  prerequisite  for  the  information  transfer 
process.  Human  intervention  is  manifested  in  establishing  local  site 
procedures  for  design  control,  user  conventions  for  application-oriented 
constructs,  and  the  use  of  "common  sense"  to  interpret  the  intended  part 
functionality. 

The  reference  model  uses  boxes  to  represent  information  formats  such  as 
the  IGES  format  and  the  native  CAD  database  formats.  Arrows  represent  the 
flow  of  information  between  these  representations.  Identifiers  enclosed 
in  small  circles  are  used  to  indicate  the  significant  functions  of  the 
model . 

Shown  at  the  top  of  Figure  1  is  the  representation  known  as  product  data. 
Product  data  is  assumed  to  be  a  fuzzy  concept  that  requires  the  agency  of 
a  knowledgeable  human  to  translate  its  imprecise  representation  into  that 
of  a  local  CAD  system.  The  representation  of  product  data  is  in  the 
domain  of  PDES  and  is  beyond  the  scope  of  this  effort. 

2.1.  A  Typical  IGES  Data  Exchange:  The  model  shows  the  CAD  data  exchange 
process  to  be  a  nearly  symmetrical  sequence  of  representations  and 
interface  processes.  The  first  element,  labeled  1,  represents  the 
designer,  engineer,  or  CAD  operator.  It  designates  the  iterative 
processing  performed  by  a  user  to  translate  the  concepts  embodied  by  the 
part  model  into  a  valid  CAD  representation.  The  actions  of  the  users  are 
governed  by  design  goals,  application  conventions,  local  procedures,  and 
the  interface  capabilities  of  the  CAD  system. 

Element  number  2  in  the  model  symbolizes  the  local  CAD  database 
representation,  its  support  systems,  and  general  capability.  CAD 
representation  and  functionality  is  of  particular  concern  for  acceptance 
testing.  Users  need  a  good  understanding  of  what  functionality  they 
require  and  how  that  functionality  is  represented  internally.  These 
issues  will  be  discussed  later  in  this  report. 

The  third  element  identifies  the  conversion  process  from  the  native  CAD 
representation  of  the  originating  system  to  the  IGES  format.  This 
process,  know  as  IGES  preprocessing,  may  be  an  integrated  module  of  CAD 
system  or  a  separate  stand-alone  utility. 

The  fourth  element  is  the  data  representation  defined  by  the  IGES 
specification  "as  seen  by  the  sending  system".  The  IGES  representation 
was  designed  to  be  a  neutral  format,  rich  in  data  elements  to  encompass 
all  CAD-related  applications.  However,  due  to  application  conventions, 
different  methods  of  encoding  information,  and  ambiguity  in  the  IGES 
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speciflcaclon,  there  cen  be  aultiple,  correct  interpretations  of  the 
information  contained  in  an  ICES  file.  For  example,  at  one  site  the 
conventions  may  dictate  using  connected  line  segments  to  indicate  fluid 
flow.  At  another  site  with  different  conventions,  this  information  may 
be  lost.  For  this  reason  the  ICES  representation  as  seen  by  sending  and 
receiving  system  are  separated.  The  difference  in  IGES  usage  is  often 
referred  to  as  "flavoring”. 

The  fifth  element  is  the  transmission  of  the  IGES  file  from  the  sending 
to  a  receiving  system.  The  manner  of  transmission  is  unspecified.  It 
can  be  via  magnetic  media,  optical  disk,  local  area  networks,  or 
telephone  link.  Typically  an  error  detection  and  correction  scheme  is 
utilized  to  ensure  data  integrity. 

Elements  six  through  nine  are  reflections  of  elements  one  through  four. 
Item  six  is  the  representation  of  an  IGES  file  as  seen  "by  the  receiving 
system" .  For  reasons  previously  stated,  the  IGES  neutral  format  can  be 
interpreted  differently  by  the  sending  and  receiving  systems. 

Element  seven  designates  the  IGES  postprocessing  step  which  converts  the 
IGES  format  into  that  of  the  receiving  CAD  system.  There  is  one 
significant  difference  between  the  interactions  of  elements  two  and  three 
versus  the  interactions  between  elements  seven  and  eight.  For  the 
preprocessing  step,  the  software  implementors  will  typically  have  a  firm 
conceptual  grasp  on  the  information  to  be  translated  to  the  IGES  format. 
It  then  becomes  a  matter  of  finding  the  most  appropriate  data  elements  in 
IGES  to  do  the  job.  On  the  other  hand,  designers  of  the  postprocessors 
need  to  be  ready  for  a  wide  variety  of  entities,  forms,  and 
functionalities . 

The  final  element  identifies  the  operations  of  a  CAD  operator  who 
inspects  the  CAD  database  and  assesses  its  correctness.  Errors  are  fixed 
according  to  the  operators  interpretation  of  the  CAD  database  and  value 
is  added  to  the  part  data.  Again  as  in  element  one,  local  application 
conventions  and  site  procedures  are  applied. 
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3.  Error  Soureag  in  Data  Exchange:  Errors  in  dats  exchange  can  be 
thought  of  as  the  failure  to  accurately  transfer  infomation  from  a 
sending  system  to  a  receiving  system.  The  failures  can  be  caused  by 
errors  of  commission  and  errors  of  omission  on  the  part  of  implementors 
and  users  of  CAD  systems.  They  can  also  be  caused  by  ambiguities  in  the 
standards  used  to  encode  and  transfer  the  data  such  as  ICES  and  the  data 
media  protocols. 

The  reference  modal  illustrated  in  Figure  1  Is  partlculary  useful  in 
looking  at  error  sources.  All  errors  can  be  associated  with  the 
representation  of  data  or  the  communication  processes  between  the 
representations.  Representation  errors  arise  from  ambiguity,  logical 
errors,  and  incompleteness.  Process  and  interface  errors  can  be 
procedural  errors,  software  bugs,  and  human  misunderstanding.  These 
error  sources  will  now  be  expanded  from  the  point  of  view  of  the  sending 
and  receiving  systems. 


3.1.  Error  Sources  from  Sending  system:  Error  sources  on  the  sending 
side  can  be  thought  of  as  origination  errors.  They  Include  software  bugs 
design  flaws,  improper  local  design  conventions,  and  errors  induced  by 
tolerancing  and  precision  problems.  Most  of  the  error  sources  in  this 
class,  especially  chose  concerned  with  engineering  and  design  practices, 
are  not  within  the  scope  of  data  exchange  errors. 


3.1.1.  Human  errors:  Human  errors  as  described  in  the  model  shown  in 
Figure  1  are  errors  introduced  by  hximan  mistakes.  These  Include  errors 
in  Che  local  site  conventions,  misuse  of  the  software  and  Che  inability 
Co  represent  part  model  information  through  the  CAD  system  interface. 
Some  of  these  errors  are  subtle  and  not  really  errors  in  their  own  right 
For  example,  a  local  sice  convention  may  use  a  particular  set  of 
geometric  elements  and  associativities  to  describe  a  high  pressure  steam 
pipe.  When  transferred  as  a  series  of  drawings  to  another  sice,  this 
information  is  lost  and  requires  human  interpretation  to  reconstruct  its 
intent.  Because  the  operator  on  Che  receiving  must  guess,  a  possible 
error  source  is  introduced  because  the  original  intent  has  become 
unclear. 


3.1.2.  CAD  Representation  errors:  CAD  representations  present  us  with 
another  error  source.  There  are  of  course  software  bugs,  which  when 
found,  can  be  fixed.  Ocher  problems  of  a  more  difficult  nature  involve, 
change  control,  inadequate  representation  functionality,  and  missing 
functionality.  As  mentioned  before,  these  latter  error  sources  are  not 
necessarily  errors  on  the  part  of  the  CAD  system.  They  arise  due  to  a 
mismatch  of  expectations  between  Che  sending  and  receiving  CAD  users  and 
sending  and  receiving  CAD  implementors. 

Change  control  error  sources  occur  when  a  system  is  modified  and  an 
unexpected  change  in  functionality  occurred.  An  example  occurred  when  a 
vendor  changed  his  text  handling  technique.  Normally  this  would  be  a 
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crlviaX  concern,  except  thet  In  one  eppllcetion  e  snail  position  shift 
occurred  on  the  lettering  of  a  printed  circuit  board.  At  the  new 
position,  the  lettering  shorted  out  two  conducting  paths  which.  In  cum, 
caused  a  board  failure. 

Hissing,  Inadequate,  and  mismatched  functionality  occurs  when  a  xiser 
cannot  represent  desired  part  functionality  In  the  CAD  database.  It  can 
also  occur  when  the  functionality  Inherent  In  the  database  cannot  be 
transferred  either  to  ICES  or  to  the  receiving  CAD  system.  Mismatched 
functionality  occurs  %rhen  the  representation  forms  on  the  sending  and 
receiving  systems  are  sufficiently  different  so  that  Identical 
functionalities  can  not  be  transferred.  Examples  of  this  have  recently 
surfaced  on  two  systems  that  had  different  conventions  for  handling  level 
and  color  information.  One  popular  CAD  system  associates  color  and  level 
so  that  only  one  color  can  be  defined  for  a  given  level.  While  this  is 
not  an  error,  test  cases  designed  to  transfer  Information  to  a  level 
using  colored  entities  were  not  successful. 


3.1.3.  ICES  preprocessing:  The  ICES  translators  are  the  most  obvious 
and  most  often  cited  sources  of  error.  Historically,  this  was  caused  by 
the  general  poor  quality  of  translator  software  and  the  lack  of  support 
given  to  ICES  translators  by  the  CAD  companies.  Modem  translators  are 
vastly  improved  over  their  predecessors  and  are  undeserving  of  their  poor 
reputations.  What  this  discussion  will  show  Is  that  many  of  the  errors 
occurring  in  the  exchange  process  are  introduced  by  differences  in 
expectations  on  the  receiving  and  sending  systems  and  not  due  to  faulty 
software. 

Errors  introduced  by  preprocessing  include:  improperly  constructed  ICES 
files,  poor  choice  of  entity  mappings,  and  the  inability  to  represent 
native  functionality  in  the  ICES  format. 


3.1.4.  ICES  format  errors:  As  stated  previously,  element  four 
identifies  the  ICES  format  as  seen  by  the  sending  system.  The  class 
includes  generic  ICES  problems  such  as  erroneous  and  ambiguous 
specifications.  These  problems  have  received  a  great  deal  of  attention 
in  the  user  community  and  will  not  be  elaborated.  A  second  source  of 
error  occurs  because  there  are  multiple,  correct  IGES  representations  for 
a  given  CAD  database  element.  When  compounded  across  the  entire  CAD 
database,  a  very  large  set  of  correct  IGES  files  can  be  generated  to 
represent  the  same  part.  In  a  data  exchange,  the  Implementor  of  a 
preprocessor  has  the  advantage  of  knowing  the  Intent  of  the  native 
database.  To  him,  having  multiple  representations  will  be  seen  as 
flexibility.  He  will  merely  choose  the  IGES  entitles  which  most  closely 
match  his  native  entitles.  The  Implementor  of  the  postprocessor  does  not 
have  this  advantage  and  must  make  assumptions  about  the  intent  of  the 
file.  Thus,  a  possible  error  source  Is  introduced. 


3.1.5.  Transmission  Errors:  Transmission  error  occurs  when  data  files 
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transmitted  from  the  sending  system  do  not  match  the  data  flies  received. 
These  errors  are  of  two  types,  transmission  and  Interpretation. 
Transmission  errors  are  usxialiy  Induced  by  noise  or  device  malfunction. 

It  can  Include  magnetic  media  failure.  Improper  head  alignment  on  a 
floppy  disk  drive  or  a  lightning  burst  over  a  telephone  line.  With 
current  error  correcting  protocols  and  modem  device  drivers,  these  are 
usually  not  a  problem.  Errors  are  more  likely  to  occur  through  the 
misinterpretation  of  the  file  structure  of  the  correct  data  files. 

Each  computer  operating  system  has  Its  otm  definition  of  what  a  file 
should  look  like.  Larger  systems  will  have  several  choices  of  file  types 
to  choose  from.  When  files  are  transferred  to  other  systems  (electronic 
bulletin  boards,  local  area  networks,  and  magnetic  media),  a  file 
structure  change  can  occur  that  Is  Invisible  to  the  user.  This  was 
dramatically  demonstrated  during  ICES  testing  at  NBS  when  valid  ICES 
files  could  not  be  postprocessed.  Fortunately,  when  the  file  type  Is 
misused,  the  error  Is  so  severe  that  It  cannot  remain  undetected. 


3.2.  Error  Sources  from  Receiving  Systems:  The  list  of  possible  error 
sources  from  a  receiving  system  accurately  mirrors  the  error  sources  from 
the  sending  system.  The  major  difference  between  the  two  sides  Is  that 
the  sender,  knowing  what  to  communicate,  must  select  a  representation  to 
capture  his  Intent.  The  receiving  system  has  an  open-ended  task.  From  a 
large  set  of  choices,  all  reasonable  constructs  must  be  Interpreted  and 
higher  orders  of  Information  associated. 


3.2.1.  Transmission  Errors:  As  mentioned  in  section  2.1.5,  transmission 
error  occurs  when  data  files  transmitted  from  the  sending  system  do  not 
match  the  data  files  received.  The  errors  are  of  two  types,  transmission 
and  interpretation.  Transmission  errors  are  usually  Induced  by  noise  or 
device  malfunction.  It  can  include  magnetic  media  failure,  improper 
head  alignment  on  a  floppy  disk  drive  or  a  lightning  burst  over  a 
telephone  Line. 

Interpretation  errors  typically  occur  because  of  differing  expectations 
of  file  and  carriage  control.  Interpretation  errors  can  be  induced  by 
either  the  operating  system  or  application  programs. 


3.2.2.  ICES  format  errors:  This  Identifies  error  sources  Inherent  in 
the  IGES  format  as  seen  by  the  receiving  system.  Included  are  the  generic 
IGES  problems  such  as  erroneous  and  ambiguous  specifications  and  chose 
Induced  by  multiple  correct  representations  of  CAD  functionality. 


3.2.3.  ICES  Postprocessing:  The  IGES  postprocessor  and  preprocessor 
share  the  dubious  distinction  of  being  the  best  known  and  most  often 
cited  error  source.  As  with  many  examples  of  "common  knowledge"  this  may 
be  untrue.  Development  of  this  representational  model  has  shown  that 
most  exchange  errors  may  occur  at  the  logical  level.  However,  this 
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assertion  of  this  needs  to  backed  up  facts  and  such  facts  are  not 
available. 

Errors  introduced  by  postprocessing  include:  improperly  constructed  ICES 
files,  no  support  for  specific  entities,  and  the  inability  to  represent 
all  entity  fimctionality  inherent  in  the  IGES  construct. 


3.2.4.  CAD  Representation  errors:  Error  sources  for  CAD  representations 
on  the  receiving  system  include  software  bugs, 

inadequate  representation  functionality,  and  missing  functionality.  As 
mentioned  before,  most  arise  due  to  a  mismatch  of  expectations  between 
the  sending  and  receiving  CAD  users  and  sending  and  receiving  CAD 
implementors . 


3.2. S.  Human  errors :  Human  errors  are  mainly  derived  from 
misinterpretations  and  errors  associated  with  site  specific  and 
application  specific  conventions.  When  human  intervention  is  necessary 
to  correct  or  restore  a  part  model,  the  operator  must  detect  those  items 
that  require  change  and  modify  them.  Since  this  is  an  iterative  process, 
the  operator  mirrors  the  originator  of  the  part.  Consequently,  he  must 
follow  local  conventions  and  be  subject  to  the  same  error  sources. 

3.3.  Conceptual  Grouping:  As  with  any  complex  process,  there  are 
multiple  ways  to  classify  its  behavior.  The  error  sources  discussed  so 
far  have  been  presented  along  sequential  and  functional  lines  of  data 
flow.  If  viewed  conceptionally ,  another  useful  grouping  of  error  sources 
emerges  with  the  concept  of  functional  intent. 

Functional  intent  can  be  defined  as  the  process  of  transferring  the 
original  design  intent  from  one  system  to  another.  This  involves  the  use 
of  a  representational  form  and  a  translation  to  and  from  the  form  as 
shown  below. 


This  process  occurs  between  each  representational  form.  From  figure  1, 
these  are  the  product  data  model,  the  sending  and  receiving  CAD 
databases,  the  human  operators  internal  modeling,  and  the  IGES  format. 
Errors  can  now  be  collected  into  these  five  categories  for  each  operation 
in  the  data  exchange  process.  However,  since  two  of  these  five 
catagories  deal  with  functional  intent  and  another  two  deal  with 
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translation  choices  we  can  reduce  the  errors  groupings  to  three  error 
classes.  A  functionality  class  Including  error  sources  chat  derive  from 
the  capabilities  of  Che  CAD  systems  to  capture  the  Intent  of  Che  original 
part  model,  a  translation  class  that  Includes  errors  generated  by 
translation  and  Interpretation,  and  finally  a  representation  class  that 
Includes  error  sources  Induced  by  the  representational  format. 

For  completeness,  a  fourth  class  Is  added  to  Include  general  operational 
errors.  This  includes  hiaan  error,  software  configuration  management 
errors,  and  transmission  noise  and  media  failure.  The  following  cable 
summarizes  these  error  sources  by  class. 
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4.  The  Hierarchy  of  IGES  Tranalator  Testing:  Before  starting  to  use 
ICES  as  a  aechanlsa  for  CAD  data  exchange  for  production  quality 
Information,  It  Is  prudent  to  test  the  translators  that  will  be  used.  As 
has  been  the  case  with  General  Motors,  Boeing,  Hughes,  the  Seawolf 
project,  and  others,  testing  Is  a  laborious  and  demanding  task.  The  cask 
Is  also  extremely  complex  and  If  approached  without  a  formal  plan,  will 
consume  tremendous  amounts  of  manpower. 

4,1.  Three  Level  Strategy:  The  IGES/PDES  Testing  Methodology  project 
has  developed  a  three  level  strategy  for  translator  testing  that  produces 
detailed  test  results  with  a  minimum  of  resources.  It  Is  based  upon  a 
division  of  workload  Into  portions  that  are  generic  to  all  users  and  CAD 
systems,  portions  that  are  common  to  a  specific  application,  and  portions 
chat  can  only  be  tested  in  the  user's  own  system  environment.  As 
previously  defined,  the  strategy  divides  testing  Into  three  levels: 


verification  -  which  focuses  on  individual  entity  tests, 

application  -  which  deals  with  entity-entity  and  entity-attribute 
Interactions ,  and 

acceptance  -  which  looks  at  system  to  system  exchanges. 

Each  level  builds  upon  work  done  at  the  lower  levels.  For  instance,  the 
application  level  testing  cannot  proceed  unless  verification  testing  has 
been  completed  on  each  entity  and  form  number  that  Is  in  the  application 
subset.  Furthermore,  this  three  level  strategy  allows  the  common  aspects 
of  all  testing  to  be  done  at  a  single  site  and  thus  supports  all  users  of 
the  IGES  translation.  Such  a  site  is  the  envisioned  SAE  national  testing 
program  to  do  verification  level  testing.  Test  results  from  the  SAE  can 
be  used  by  all  application  level  testing  and  those  in  turn  are  used  in 
acceptance  level  testing. 


4.2.  Gathering  Data  on  CAD  Error  Sources:  A  comprehensive  data  gathering 
effort  must  be  looked  at  from  several  different  perspectives.  The  first, 
and  the  basic  building  block  for  the  others,  is  gathering  data  on 
specific  CAD  systems.  Specific  error  sources  Induced  by  specific 
systems  need  to  be  cataloged  in  both  preprocessor  and  postprocessor 
modes.  This  is  the  verification  test  which  Includes  a  comprehensive 
approach  for  Intra-system  testing  and  data  gathering  to  accurately 
characterize  the  features  of  a  given  system  and  check  those  features  for 
conformance  with  the  IGES  Specification.  At  this  time,  these  tests  are 
being  developed  and  tested.  Specifics  of  the  "Qulckstart"  Implementation 
will  be  discussed  in  the  next  section  on  verification  level  testing  with 
the  actual  results  presented  In  Appendix  C. 

The  second  front  for  data  gathering  is  in  the  area  of  application  level 
testing.  IGES  application  subsets  have  been  defined  for  three  candidate 
applications.  It  is  expected  that  as  the  necessary  information  models 
become  available  and  usage  guides  written,  error  analysis  will  begin. 
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The  final  front  is  concerned  with  errors  generated  on  specific  systems  at 
specific  test  sites.  Data  gathering  and  analysis  of  inter-system  data 
exchange  is  the  subject  of  acceptance  testing.  This  process  is  the  most 
important  to  the  end  xiser  because  it  will  show  what  errors  he  can  expect 
in  his  own  shop  and  provide  guidance  for  avoiding  them.  Error  detection 
and  correction  lies  at  the  heart  of  the  acceptance  testing  concept. 
Consequently,  it  will  be  discussed  with  the  acceptance  testing  section  in 
this  report. 

The  verification  test  is  a  very  important  component  of  the  acceptance 
test.  Basic  operations  done  during  the  verification  process  must  also  be 
performed  for  the  acceptance  test,  (the  derivation  and  testing  of  the 
entity  map  being  the  most  significant).  Uithout  the  verification  results, 
the  end  user  would  have  to  design  his  own  sits  specific  verification  test 
to  gage  ICES  performance  and  characterize  his  CAD  systems  prior  to 
investigating  inter-system  data  exchange.  This  burdensome  function  would 
be  further  duplicated  at  other  sites  that  are  attempting  to  come  to  terms 
with  their  CAD  data  exchange  needs.  Acceptance  testing  is  discussed  in 
Section  6  and  Appendix  E. 
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5.  Verification  Level  Testing;  Verification  Testing  Is  the  first  part 
of  a  three  part  process  aimed  at  Improving  the  i^uallty  of  digital  product 
data  transfer.  It  addresses  the  concept  of  vendor  claims,  the 
correctness  of  Individual  entitles  read  Into  and  written  from  CAD/CAM 
systems,  and  overall  conformance  to  the  ICES  specification. 

S.l.  Approach:  The  goal  of  the  Verification  Testing  effort  Is  to 
establish  an  Independent,  national  program  to  test  IGES  translators.  The 
trial  phase  of  the  program,  tdileh  will  be  run  by  the  Society  of 
Automotive  Engineers  will  help  establish  a  defined  level  of  quality  for 
IGES  translators. 

A  key  concept  In  Verification  Testing  Is  that  of  the  vendor  claim.  Unlike 
most  standards,  IGES  Is  not  designed  to  be  fully  Implemented  by  system 
Implementors.  This  circumstance  arises  from  the  richness  and 
application-specific  entitles  In  the  IGES  specification.  System 
designers  Implement  chose  entitles  which  are  meaningful  for  their 
application  areas.  As  a  consequence.  It  Is  necessary  to  determine  what  an 
IGES  translator  supports  and  what  restrictions  are  placed  on  Its  use.  To 
capture  this  Information,  the  concept  of  the  vendor  claim  was  developed. 
It  consists  of  the  following. 


o  Postprocessor  Entity  Hap 
o  Preprocessor  Entity  Map 
o  Definition  of  functionality  for  the  maps 
o  Statement  of  system  limits 


It  is  the  objective  of  the  Verification  Test  to  cake  the  vendor  claims 
and  "verify"  that  they  are  correct  through  the  use  of  the  IGES  test 
library  and  analytical  comparisons.  The  actual  tests  will  be  run  by  a 
testing  agency  selected  by  the  SAE. 

Results  from  the  testing  agency  will  be  reviewed  by  the  IGES  Verification 
Panel,  which  is  made  up  of  IGES  members,  IGES  users,  and  industry 
representatives.  The  panel  will  evaluate  the  results  of  the  tests  and 
produce  its  findings.  If  necessary,  a  30-day  review  period  will  be 
granted  for  negotiations  with  the  vendor  and  retesting.  Following  that 
period,  a  verification  report  Is  Issued  stating  the  claims  that  have  been 
verified.  The  Verification  Panel  will  be  under  the  jurisdiction  of  the 
SAE  Review  Board  which  monitors  the  activity  of  the  testing  program. 

The  Verification  program  will  have  to  ramp  up  for  complete  Version  3.0 
testing  over  a  period  of  two  years.  Over  two  thousand  test  cases  and 
test  scripts  with  accompanying  documentation  and  expected  results  must  be 
produced.  This  will  clearly  take  time  and  effort.  Since  It  Is 
unreasonable  to  delay  the  start  of  testing  until  all  IGES  capabilities 
can  be  evaluated,  a  phased  approach  will  be  used.  An  Initial  selection 
of  Phase  I  entitles  has  been  chosen  from  the  DOD  Technical  Publication, 
Engineering  Drawing,  and  Printed  Circuit  Board  application  subsets. 
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The  different  phases  of  the  testing  program  are  defined  below.  The 
Preliminary  Phase  and  Phase  I.  are  described  in  detail  by  the  appendices. 
This  approach  allows  for  a  trial  testing  period  during  Phase  I.,  which 
will  accommodate  the  need  for  internal  testing  and  debugging. 


Preliminary 

Establish  Che  testing  program  and  develop  supporting 
documentation  and  test  cases.  This  phase  is  running  now 
and  will  continue  through  the  end  of  calendar  1987 . 

Phase 

I 

Start  program  in  "trial  mode”  and  add  increasing  levels 
of  testing  complexity.  Most  testing  will  be  manual. 
Phase  will  run  all  of  calendar  1988. 

Phase 

II 

Add  software  cools  to  do  more  complete  analysis  of  ICES 
processors.  Begin  adding  Version  4.0  entities.  Phase 
will  run  all  of  calendar  1989. 

Phase 

III 

Begin  automating  the  testing  sequences.  Add  Version  5.0 
entities  and  new  tools  for  analyzing  surfaces . 

Phase  will  run  through  1990. 

5.2.  Methodology  Development:  The  basic  concepts  of  Verification 
testing  have  been  in  place  since  1986.  The  next  step  required  chat  these 
concepts  be  expanded  and  translated  into  detailed  instructions  for  Chose 
persons  performing  the  test.  To  this  end,  two  projects  were  undertaken 
CO  develop  and  Cest  chese  procedures.  They  have  since  been  dubbed 
"Quickscart"  and  "Quickscarc  jr." 

5.2.1.  "Quickscart" :  The  "Quickscart"  approach  was  defined  so  that  a 
National  Verification  Program  could  be  started  in  the  near  future.  This 
approach,  led  to  the  development  of  the  material  in  Appendix  A. 
"Quickscart"  broke  verification  testing  into  smaller  problem  domains  and 
created  a  time  cable  for  addressing  unresolved  technical  issues. 

It  is  important  to  recognize  chat  the  "Quickscarc"  approach  did  not 
replace  the  existing  testing  methodologies.  It  produced  an 
implementation  strategy  for  chose  methodologies.  Furthermore,  even  though 
subsets  were  used  to  defined  the  initial  set  of  entities  to  be  tested, 
"Quickscarc"  testing  must  not  be  confused  with  application  subset 
testing. 


5.2.2.  "Quickscart  1r.":  The  SAE  program  requires  clear  and  detailed 
instructions  to  guide  its  testing.  Creating  and  testing  chese 
verification  procedures  on  real  systems  was  the  subject  of  the  three 
month  effort  called  "Quickscart  jr." 

The  purpose  of  "Quickscarc  jr."  was  to  provide  a  validation  of  all  the 
relevant  material  on  testing  methodology  developed  for  the  planned  SAE 
Test  Program  and  to  assess  its  completeness  and  technical  quality  on  a 
narrow  set  of  entity  types.  Once  the  methodology  was  proven  using  a  few 
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test  cases,  the  full  breadth  of  teat  eases  needed  for  a  national  testing 
prograa  could  be  developed. 

Specific  tasks  accomplished  in  the  "Quickstart  Jr.*  project  included: 

o  Production  of  a  detailed  overview  of  entire  verification  process. 

o  Creation  of  detailed  step-by-step  pre  and  postprocessor  testing 
plana. 

o  Production  of  five  complete  test  eases  with  documentation, 
construction  scripts,  and  verification  criteria  -  line,  arc, 
general  note,  angular  dimension  and  subfigure. 

o  Tests  of  procedures  on  4  CAD  systems. 

o  Production  of  a  prototype  SA£  Verification  Report. 

o  Presentation  of  results  to  ICES  testing  committees 

The  project  produced  a  detailed  set  of  step-by-step  procedures  for 
testing  both  preprocessors  and  postprocessors  as  well  as  suggestions  for 
revising  the  various  ICES  testing  methodology  documents.  Also  resulting 
from  the  project  were  a  set  of  all  forms  needed  for  data  gathering,  five 
fully  completed  test  cases  and  an  example  "SAE  Style"  test  report  on  each 
of  four  CAD  systems. 

NBS  in  conjunction  with  the  IGES/PDES  Methodology  Testing  Committee,  two 
CAD  Vendors,  and  staff  from  the  Naval  Surface  Weapons  Center,  che  Navy's 
David  Taylor  Research  and  Development  Center,  and  Army's  Labcom  at  Ft. 
Monmouth  initiated  a  test  of  the  SAE  procedures  using  five  ICES  test 
cases,  a  specific  set  of  test  instructions,  and  four  separate  sices. 

The  first  steps  were  to  develop  the  detailed  test  procedures  and  select  a 
group  of  sample  test  cases.  The  test  cases  chosen  for  the  effort  were 
Che  line,  general  note,  angular  dimension,  circular  arc,  and  subfigure. 
The  procedures  were  derived  from  the  testing  methodology  document.  The 
test  procedures  are  included  in  Appendix  A. 
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The  first  iteration  uncovered  a  series  of  problems  that  had  to  be  quickly 
dealt  with.  These  included: 

o  difficulty  in  following  the  test  procedures. 

o  errors  in  test  cases, 

o  difficulty  with  the  construction  details  for  preprocessor  tests 
on  some  systems, 

o  difficulties  in  design  philosophy  of  one  CAD  system  that  made  the 
postprocessor  test  cases  useless. 

The  problems  encountered  on  the  first  iteration  led  to  a  much  improved 
second  iteration.  For  this  pass  a  series  of  entity  test  cases  were 
created  that  contained  no  extra  colors,  line  fonts,  levels  or  text  fonts. 

Next,  a  system  of  forms  was  designed  to  help  guide  the  testing  teams 
through  the  procedures  and  help  the  reporting  of  results.  It  was  felt 
that  the  most  efficient  way  to  capture  the  intent  of  the  testing 
methodology  was  to  embed  it  in  forms  rather  than  text.  This  led  to  the 
development  of  a  new  forms  packet  which  is  included  with  the  verification 
procedures  in  Appendix  A. 

The  results  of  the  second  iteration  were  far  superior  to  the  first.  Some 
minor  problems  with  the  test  cases  remained  but  very  useful  data  was 
obtained.  These  results  will  form  the  basis  for  developing  the 
verification  methodology  in  the  coming  months.  Results  of  "Quickscacrc 
jr"  are  shown  in  Appendix  C.  and  were  presented  at  the  St.  Louis  meeting. 


5.2.3.  Methodology  Review:  In  order  to  demonstrate  our  methods  and 
bring  more  members  of  the  ICES  community  into  active  participation  with 
the  testing  effort,  a  live  verification  test  was  performed  and  a  homework 
exercise  was  created.  The  live  test  featured  two  CAD  vendors,  Autodesk 
and  Cadkey,  who  supplied  their  systems  and  an  operator  for  the  test.  The 
procedures  specified  in  Appendix  A  of  "Testing  Methodology  of  ICES 
Translators  and  IGES  Formatted  Data  Files  Version  0.5"  were  followed  with 
a  set  of  verification  test  forms  contained  in  the  Verification  Request 
Packet.  These  were  filled  out  during  the  test,  except  for  the  vendor 
claims,  which  had  been  entered  prior  to  the  test. 

A  verification  test  is  a  tedious  process.  Briefly,  the  test  proceeded  as 
follows : 

o  The  test  team,  vendors,  and  observers  were  assembled  and  a  test 
log  was  initiated. 

o  The  hardware  and  software  configurations  were  verified. 

o  The  Volunteer  Entity  Test  was  run. 

o  The  Global  Section  values  were  checked  against  those  expected 
from  the  vendor  claims. 

o  The  test  plan  was  run  for  preprocessor  testing  of  the  line  and 
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o 


genaral  note  entities. 

The  test  plan  was  run  for  postprocessor  testing  of  the  line  and 
general  note  entities, 
o  The  results  were  analyzed. 

Both  systems  behaved  well  and  produced  a  credible  showing.  The  Autocad 
system  displayed  more  of  the  fvinctional  sub -components  of  the  general 
note  than  the  Cadkey  system.  This  gave  the  illusion  that  it  handled  the 
test  better.  The  observers  were  reminded  that  verification  testing  is 
not  a  competitive  event,  and  the  test  results  are  not  a  Judgement  of 
system  quality. 

Two  Incident  Reports  were  generated  on  the  Autocad  system  for  the  general 
note  postprocessor  test.  The  entitles  were  displaced  from  their  expected 
location.  Analysis  of  the  incident  produced  three  differing  views.  1  - 
the  test  case  is  in  error.  2  -  the  Autocad  postprocessor  is  in  error,  and 
3  -  the  general  note  definition  is  ambiguous.  Further  discussion  will 
resolve  the  issue.  Autodesk  has  stated  that,  if  the  problem  is  in  their 
software,  they  will  fix  it  immediately. 

From  this  demonstration  two  important  points  were  illustrated.  The  first 
is  that  verification  is  a  slow,  yet  vital  process  requiring  care  and 
commitment  on  the  part  of  the  testers.  The  second  is  that  many  of  the 
incidents  reported  in  the  early  phases  of  testing  will  be  about  the  test 
cases.  Discovery  of  ambiguity  in  test  cases  and  procedures  are  welcome. 
Once  discovered,  they  can  become  the  subject  of  corrections  and 
recommended  practices. 

The  data  gathering  by  the  "Quickstart  Jr"  effort  established  the 
information  needed  for  the  SAE  program.  Building  on  this  work,  a 
homework  exercise  was  created  to  get  more  testing  committee  members 
involved  in  the  effort  ard  to  gather  data  from  a  wider  range  of  CAD 
systems.  The  exercise  packet  contained  test  cases,  blank  verification 
foirms,  and  the  verification  procedures. 


5.2.4.  Lessons  Learned:  The  development  of  the  implementation  approach 
and  Che  public  demonstration  highlighted  the  following  points. 

o  Test  cases  are  much  harder  to  design  and  perfect  chan  first 
imagined. 

o  A  complete  and  comprehensive  set  of  forms  is  necessary  to  capture 
Che  testing  methodology  and  guide  testers  through  the  procedures. 

o  Verification  is  a  slow  process. 

o  Verification  forms  are  numerous  and  the  results  are  massive.  It 
will  be  necessary  to  have  computer  assistance  for  the  testing, 
data  gathering,  and  data  analysis  process. 

o  CAD  system  limitations  and  design  features  play  a  larger  role  in 
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test  esse  design  and  selection  than  expected. 

Nevertheless,  the  testing  methods  have  been  developed  and  validated,  the 
set  of  forms  printed  and  tested,  and  several  live  tests  performed.  The 
remaining  testcase  suite  development  is  twdervay  and  should  be  complete 
under  the  "Quicks tart"  scope  in  time  to  support  the  SAE  program. 


S.3.  Role  of  the  Society  of  Automotive  Engineers:  The  ICES  testing 
program  will  be  sponsored  by  the  Society  of  Automotive  Engineers.  It  is 
one  of  several  testing  programs  administered  by  them.  There  are  four 
groups  which  participate  in  the  testing  program:  the  SAE  staff,  the 
Performance  Review  Board,  the  ICES  Verification  Panel,  and  the  testing 
agency (ies). 


5.3.1.  SAE  Staff:  The  staff  of  the  SAE  has  administrative 
responsibility  for  the  testing  program.  These  responsibilities  include: 

o  Provide  administrative  services  and  support. 

o  Arrange  logistics  of  meetings  including  meeting  facilities. 

o  Maintain  detailed  financial  information  on  incomes  and 

expenditures  of  the  IGES  Verification  Program.  Provide  such 
information  to  the  Technical  Board  to  assist  it  in  establishing 
appropriate  fee  structures. 

o  Arrange  for  appropriate  legal  coxonsel  and  report  the  findings  and 
recommendations  of  legal  counsel  to  the  IGES  Verification  Panel. 

o  Arrange  for  appropriate  indemnification  insurance  for  the  IGES 
Verification  Panel. 

o  Assure  compliance  with  all  prescribed  forms  and  Procedures 
involving  the  IGES  Verification  Program. 

o  Hire  a  capable  agency (ies)  to  perform  the  testing  and  provide 
contract  administrative  support. 

o  Maintain  appropriate  records. 

o  Establish  and  maintain  procedures  to  ensure  the  confidentiality 
of  certain  results  as  appropriate. 

5.3.2.  Performance  Review  Board:  The  SAE  Performance  Review  Board 
serves  as  an  overseer  for  the  various  review  Panels  sponsored  by  the  SAE. 
The  Board  reviews  and  approves  the  operating  procedures  of  the  review 
panels  as  well  as  their  membership. 
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S.3.3.  IGES  Verification  Panel:  Th«  ICES  Verification  Panel  shall  come 
under  the  Jurisdiction  of  and  report  directly  to  the  SAE  Performance 
Review  Board.  It  shall  be  composed  of  people  who  are  technically 
competent  in  the  area  of  IGES  and  CAD  data  exchange. 

Subject  to  approval  by  the  SAE  Performance  Review  Board,  the  IGES 
Verification  Panel  shall  formulate  operating  procedures,  rules  and 
operating  guidelines.  These  guidelines  will  ensure  that  the  testing 
program  adequately  serves  all  interested  parties,  including  industry  and 
the  general  public,  while  adhering  to  the  principles,  policies,  and 
objectives  of  the  SAE. 


The  work  of  the  IGES- Verification  Panel  is  to  review  the  test  criteria, 
testing  techniques,  and  the  results  of  the  testing  agency  to  verify  that 
IGES  pre  and  postprocessors  satisfy  the  requirements  of  data  exchange  as 
referenced  in  the  NBS  IGES  specification.  It  is  the  responsibility  of  the 
IGES  Verification  Panel  to  issue  the  formal  verification  results  based  on 
the  findings  of  the  testing  agency(ies).  The  panel  may  issue  a  statement 
setting  forth  the  review  and  the  determination  it  makes  to  verify  or 
dispute  the  conclusion  reached  by  the  testing  agency(ies).  It  is  not 
anticipated  that  the  scope  of  the  Verification  Panel's  work  will  include 
verification  of  all  the  underlying  hardware  and  supporting  software  for 
the  translators. 


The  IGES  Verification  Panel  shall  consist  of  adequate  membership  to 
reflect  Che  views  of  the  users,  interested  agencies,  laboratory  testing, 
and  ocher  interested  and  affected  parties.  Initially,  the  membership 
shall  be  appointed  by  the  SAE  Performance  Review  Board.  Subsequent 
membership  will  also  be  approved  by  this  Performance  Review  Board. 

Specific  obligations  and  duties  of  the  IGES  Verification  Panel  are  given 
in  Appendix  F. 


3-3.4.  Testing  Aeencv:  The  testing  agency  shall  be  responsible  for 
verifying  the  hardware  and  software  configurations,  assembling  the 
appropriate  test  cases,  performing  the  tests,  and  reporting  the  results 
to  the  IGES  Verification  Panel. 


3-3.5.  Scheduling  of  Verification  Tests;  Schedules  for  testing  are  to 
be  arranged  by  the  testing  party.  However,  due  to  the  frequency  at  which 
software  releases  are  made  and  the  number  of  vendors  potentially  seeking 
verification,  it  is  suggested  that  if  verification  tests  cannot  be 
arranged  on  demand,  that  verification  periods  be  regularly  scheduled  on 
at  a  least  quarterly  basis. 
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5.3.6.  Funding :  The  charges  for  this  service  shall  be  such  chat  the 
IGES  Verification  Prograa  is  self-supporting.  Fiscal  policy  for  the 
program  shall  be  established  and  monitored  by  the  SA£  Performance  Review 
Board. 
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6.  Apoltcatlon  Level  Testing:  Work  during  FY  87  on  application  subsets 
resulted  In  the  creation  of  a  military  specification  on  ICES  application 
subsets  covering  technical  Illustrations,  engineering  drawings  and 
electrical/electronic  applications.  Testing  of  translators  at  the 
applications  level  builds  upon  the  earlier  verification  level  but  places 
additional  conditions  on  completeness  and  range  of  values.  Each 
application  subset  specifies  entity  and  form  number  requirements,  entity 
construction  details,  and  ranges  for  parametric  values  within  certain 
entitles.  Each  of  these  requirements  has  a  corresponding  testing 
procedure.  Details  of  the  test  procedures  for  the  three  applications 
mentioned  are  documented  In  the  same  military  specification.  See  section 
4.0  of  MIL-D-28000. 
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7.  Aceencanca  Level  Testing:  Aceepcance  testing  differs  in  three  major 
aspects  from  application  testing.  The  first  is  that  it  is  site-specific 
and  Involves  known  parameters:  specific  systems,  specific  releases  of  CAD 
software,  and  known  applications.  The  second  aspect  is  that  data  is 
transferred  across  application  areas.  This  leads  to  the  third  aspect, 
which  is  "100%  data  transfer  is  often  not  required  nor  possible". 

When  data  is  transferred  from  one  application  to  another,  only  a  certain 
amount  of  the  available  information  is  useful  to  the  new  application. 

The  other  data  may  be  useful  to  other  applications,  but  not  to  the  target 
application.  For  example,  when  a  fully  annotated  part  model  is  sent  from 
design  to  NC  production,  only  the  part  geometry  and  manufacturing  details 
are  of  interest.  The  fact  chat  the  NC  generation  system  does  not  fully 
implement  the  general  note  entity  or  support  line  fonts  may  be  of  little 
consequence.  This  allows  the  local  engineers  and  technicians  to  narrow 
their  testing  focus  to  the  most  important  aspects  of  their  data  flow. 


7.1.  Introduction  to  Acceptance  Testing. 

It  is  the  responsibility  of  the  end  users,  (those  people  who  have  the 
responsibility  for  moving  CAD  data  between  dissimilar  systems,  and  for 
validating  the  results  of  those  transfers) ,  to  determine  the  suitability 
of  ICES  translators  for  their  applications  and  operating  environments. 

It  is  impossible  for  a  single,  independent  agency  to  provide  the  level  of 
testing  required  to  make  this  determination  for  all  users.  Therefore,  it 
is  up  CO  the  end  users  to  examine  their  own  environments  and  to  devise 
appropriate  tests  to  ensure  chat  the  proposed  translators  will  perform 
adequately.  However,  Che  cask  is  simplified  if  verification  and 
application  level  testing  has  been  accomplished  previously. 

The  objective  of  an  acceptance  test  is  to  determine  whether  a  specific 
pair  of  ICES  translators  adequately  preserve  the  intended  information 
concent  while  moving  Che  associated  data  between  sending  and  receiving 
systems.  In  this  context,  the  information  content  of  interest  in  a  part 
model  is  that  which  will  be  required  by  applications  running  on  receiving 
systems  downstream  from  the  sending  system. 

Another  way  of  looking  aC  this  situation  is  that  we  are  crying  to  answer 
Che  question:  "Is  this  way  of  transferring  product  data  better  than  the 
current  way  of  doing  it?"  In  many  cases,  the  baseline  for  data  transfer 
is  Che  engineering  drawing  along  with  additional  textual  documentation. 
Therefore,  we  are  interested  in  comparing  the  total  costs  co  effect  the 
data  transfers.  In  both  the  baseline  case  and  the  case  being  evaluated, 
Che  costs  should  include  such  factors  as  the  costs  to  create  the 
information  initially,  to  transfer  che  information,  to  repair  any  damaged 
information  and  to  recreate  any  missing  information. 

Testing  of  Che  IGES  translator  pair  is  necessary  to  determine  the 
reliability  of  che  information  exchange.  The  amount  of  testing  done 
should  be  directly  related  to  che  cost  to  che  enterprise  of  any  erroneous 
or  lost  information.  In  accordance  with  this  idea,  che  test  cases  should 
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be  reviewed  end  updeted  perlodlcelly  to  reflect  the  increased  deaands  on 
the  information  exchange,  and  the  entire  test  suite  should  be  rerun 
periodically  to  Identify  any  degradation  of  the  translators  as  well  as  to 
certify  new  versions  of  the  translators.  Because  of  this  need  to  perform 
acceptance  testing  repeatedly,  a  significant  concern  to  the  test  designer 
should  be  the  ease  of  running  and  evaluating  the  test  cases.  A  more 
detailed  discussion  of  acceptance  test  procedures  and  the  design  of 
acceptance  testa  will  be  found  in  Appendix  E. 


The  IGES  Verification  Program  described  else%ihere  in  this  document  will 
provide  a  solid  basis  for  acceptance  testing  by  assuring  that  the  entity 
mapping  claimed  by  the  Implementor  of  a  translator  accurately  reflects 
the  processing  carried  out  by  that  translator,  and,  in  the  case  of 
preprocessors,  that  the  ICES  entities  are  correctly  formed.  Once  the  end 
user  is  aware  of  the  capabilities  and  limitations  of  the  translators,  a 
more  controlled  and  effective  data  exchange  can  take  place  between 
dissimilar  systems. 

The  results  of  the  verification  testing  for  a  translator  play  an 
important  role  in  assessing  how  effective  the  data  exchange  will  be. 

These  results  include  the  translator's  entity  map  along  with  the  findings 
of  the  verification  testers  concerning  the  preservation  of  functionality 
and  the  correctness  of  the  entity  formulations. 


7.2.  Use  of  entity  Mapping  in  Data  Exchange:  In  general,  entity  mapping 
can  be  described  as  the  manner  in  which  the  implementor  of  a  translator 
has  defined  the  correspondence  between  native  entity  forms  (i.e.,  the 
entity  form  maintained  within  a  system)  and  the  IGES  entity  forms  (i.e., 
the  entity  form  contained  in  the  IGES  specification) .  For  example ,  a 
string  of  curve  and  line  segments  on  a  system  may  be  translated  into  a 
Composite  Curve  entity  (Type  102)  by  a  preprocessor.  This  correspondence 
of  a  string  in  the  native  form  to  a  Composite  Curve  in  the  IGES  form  is 
the  preprocessor's  entity  mapping  for  the  native  string  entity. 

Similarly,  a  postprocessor  may  translate  a  Copious  Data  entity  (Type  106) 
into  a  30  line  entity  on  the  receiving  system  under  some  circumstances. 
Thus,  the  correspondence  of  the  Copious  Data  entity  to  the  line  entity  is 
the  postprocessor's  entity  mapping  for  the  IGES  Copious  Data  entity. 

The  forms  for  the  preprocessor  entity  map  shall  include  the  names  of  the 
native  entities  supported  and  the  names  of  their  corresponding  IGES 
entities  along  with  the  letter  designation  which  identifies  the  degree  to 
which  the  functionality  of  the  native  entity  is  preserved  in  the 
translation.  The  forms  for  the  postprocessor  entity  map  shall  include 
Che  names  of  the  IGES  entities  supported  and  the  names  of  their 
corresponding  native  entities  along  with  the  letter  designation  which 
identifies  the  degree  to  which  the  functionality  of  the  IGES  entity  is 
preserved  in  the  translation  with  respect  to  the  local  sice.  These 
letter  designations  are  explained  in  the  section  dealing  with  reporting 
Che  results  of  the  verification  tests. 
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The  entity  ups  can  be  used  as  a  first  step  in  deteraining  how  well  data 
can  be  exchanged  between  two  systeu.  Knowing  the  native  entities  which 
are  to  be  used  on  the  sending  (or  initiating)  systea,  the  end  user  can 
follow  each  entity  through  the  entity  up  for  that  system's  preprocessor 
and  the  corresponding  entity  up  for  the  receiving  system's  postprocessor 
to  see  what  the  resulting  entity  will  be.  The  end  user  can  also  get  an 
indication  of  how  good  the  translation  of  each  entity  will  be  by  looking 
at  the  corresponding  letter  desigutions  for  both  translators. 

Depending  on  the  end  user's  application  of  the  inforution  being 
exchanged,  imperfections  in  the  upping  and  translations  uy  be 
tolerable.  Acceptance  teats  should  be  performed  to  determine  the  effects 
of  imperfections  on  the  overall  inforution  exchange.  Based  on  the 
results  of  the  acceptance  testing,  the  end  user  can  strive  to  improve  the 
quality  of  the  information  exchange  by: 


o  uklng  use  of  options  provided  by  the  translator, 

o  exploring  alternative  entity  uppings  with  the  translator 

implementors, 

o  documenting  errors  found  in  translators  during  acceptance 
testing, 

o  adding  to  and  deleting  from  the  list  of  native  entities  being 
used,  and/or, 

o  developing  intermediate  processors  to  deal  with  "flavoring” 
during  translation. 

Flavoring  is  a  term  that  is  used  to  describe  particular  practices  built 
into  translators  to  handle  situations  which  are  not  covered  by  the  ICES 
specification,  or  situations  where  the  native  system  has  a  peculiar 
method  of  handling  some  data.  For  preprocessors  this  uy  be  the  case 
where  the  underlying  system  supports  entities  or  relationships  which  are 
not  directly  supported  by  IGES.  For  postprocessors  this  may  be  the  case 
where  the  underlying  system  does  not  handle  the  specific  entities  or 
relationships  supported  by  IGES.  Since  the  manner  in  which  these 
situations  are  handled  are  not  standardized,  other  knowledge  is  needed 
than  that  available  in  the  IGES  specification.  This  additional  knowledge 
is  frequently  built  into  the  translators. 


7.3.  The  Desim  of  an  Acceptance  Test:  The  seeds  for  success  of  an 
acceptance  test  lie  in  constructing  suitable  test  cases  which  will 
adequately  reflect  the  user's  need  for  inforution  exchange.  The  first 
step  in  designing  an  acceptance  test,  then,  is  to  identify  the 
information  content  of  the  data  files  to  be  passed.  One  way  to  begin 
this  task  is  to  identify  all  of  the  entities  which  are  used  by  the  people 
who  create  these  files  on  the  sending  system.  The  question  is  then  asked 
for  each  entity,  "What  inforution  does  this  entity  convey  in  the  content 
of  the  data  file?"  In  some  cases,  the  information  content  may  be 
conveyed  by  a  group  of  entities  instead  of  by  a  single  entity.  In  a 
similar  manner,  the  inforution  requirements  of  the  receiving  system  are 
identified.  Finally,  the  intersection  of  these  two  sets  of  information 
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may  ba  dataralnad.  Ic  la  this  final  list  of  information  which  provides 
the  basis  for  both  the  design  of  the  test  cases  and  the  evaluation  of  the 
results . 

The  identification  of  the  information  content  is  an  iterative  process 
which  may  involve  negotiations  between  the  senders  and  receivers  of  the 
data  files.  Some  of  the  negotiations  may  involve  making  modifications  to 
the  modeling  standards  and  conventions  of  one  or  both  of  the  parties  to 
the  information  exchange. 


7.4.  The  Design  of  the  Acceptance  Teat  Models:  For  the  purposes  of  this 
work,  a  test  model  is  defined  as  a  test  case  which  resides  on  either  the 
sending  or  receiving  system  in  that  system's  native  data  form.  These 
test  cases  will  vary  considerably  in  complexity,  but,  in  general,  will  be 
more  complex  and  more  application  specific  than  the  test  cases  used  for 
verification  testing. 

There  are  several,  general  principles  which  should  be  followed  in 
creating  the  acceptance  test  models: 

o  Each  different  entity,  or  group  of  entities,  which  occur  in  the 
information  model  should  appear  at  least  once  in  the  collection 
of  test  models. 

o  Several,  small,  simple  test  models  are  preferred  over  one,  large, 
‘  complex  test  model.  The  smaller  models  will  be  easier  to  build, 
easier  to  validate,  and  their  results  easier  to  evaluate.  In 
addition,  the  results  of  large,  complex  test  models  have  to  be 
examined  much  more  carefully  to  ensure  that  no  errors  have  been 
caused  as  a  secondary  effect  of  another  error  in  processing  the 
model.  Some  complex  models  may  be  required  as  a  part  of  the 
test,  but  these  should  be  kept  to  a  minimvus. 

o  Include  limiting  (or  boundary)  conditions  if  they  are  important 
to  the  information  exchange.  Into  this  category  fall  models  of 
large  objects  with  small  tolerances  (e.g.,  1597  +/■  0.00001).  As 
another  example,  if  the  use  of  layers  is  important  in  the  user 
environment,  include  in  a  model  the  use  of  layers  which  fall  at 
each  end  of  the  range  of  available  layers. 

o  Where  possible,  test  models  should  be  self-checking.  Redundant 
data  should  be  included  in  the  model  to  simplify  its  evaluation. 
For  example,  a  test  model  with  a  surface  could  also  contain 
several  curves  which  define  the  intersection  of  the  surface  with 
specific  planes.  (This  assumes,  of  course,  that  an  earlier  test 
model  has  validated  the  use  of  the  curves.) 

o  Create  a  script  describing  how  to  generate  each  test  model.  This 
could  be  in  the  form  of  a  command  file  for  these  systems  which 
support  this  feature.  This  script,  along  with  an  annotated 
display  of  the  test  model,  should  be  included  in  the 
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docuaentaClon  for  the  test  model. 


o  Eech  test  model  should  be  eccompenied  by  e  script  describing  how 
to  evalueta  the  results  of  the  test.  The  script  should  contain 
specific  evaluation  procedures  and  the  quantifiable  results  where 
possible.  This  script  should  also  be  included  in  the 
documentation  for  the  test  model. 

A  sample  suite  of  test  models  (and  their  corresponding  ICES  files)  for  an 
acceptance  test  is  included  in  Appendix  E. 

It  is  important  to  recognize  that  the  intent  of  an  acceptance  test  is  not 
to  exercise  the  translators  exhaustively  for  all  possible  occurrences  of 
an  entity,  but  rather  to  seek  assurance  that  the  sxibset  of  occurrences 
that  the  user  is  likely  to  see  can  be  accommodated.  As  a  result  of  this 
understanding,  pathological  problems  (e.g.,  a  zero-length  line  or  a  zero- 
radius  arc)  need  not  be  considered  unless  they  are  to  be  used  to  convey 
specific  information. 


7.5.  The  Evaluation  of  the  Results:  The  results  of  the  acceptance  tests 
should  be  evaluated  in  the  light  of  preservation  of  information  content 
(i.e.,  "Has  the  information  content  of  the  test  model  been  preserved?”). 
This  is  most  easily  done  by  examining  the  errors  which  were  identified 
during  the  test  and  asking  whether  the  errors  diminish  the  information 
content  of  the  model  for  the  application  on  the  receiving  system.  As  an 
example,  if  the  application  on  the  receiving  system  is  M/C  programming, 
the  preservation  of  text  parameters  in  the  drawing  annotation  (e.g., 
height,  width,  and  intercharacter  spacing)  may  not  be  important,  while 
Che  preservation  of  accuracy  in  the  geometry  would  be. 

A  useful  measure  of  the  effectiveness  of  a  transfer  is  given  by  comparing 
the  amount  of  time  required  to  translate  a  test  model  from  the  sending 
system  (both  pre-  and  post-processing,  tl)  and  the  time  to  repair  the 
test  model  on  the  receiving  system  (t2)  with  the  amount  of  time  required 
to  recreate  the  entire  test  model  on  the  receiving  system  (t3): 

tl+c2 

(  1 .  )  *  100% 

t3 
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8.  Software  Tools:  The  development  and  use  of  software  tools  Is  an 
important  concern  for  the  IGES  Testing  Project.  The  existence  of  a  set 
of  software  tools  that  is  useful  and  of  reasonable  cost  is  crucial  to  the 
success  of  the  project. 

Ideally,  the  tools  for  IGES  testing  should  be  in  the  public  domain  or 
readily  available,  supported,  commercial  products.  To  some  extent  this 
has  happened.  Figure  4  shows  a  list  of  IGES-related  software  products 
that  are  known  to  be  available. 

To  date,  there  have  been  a  number  of  attempts  to  completely  specify  and 
describe  the  requirements  for  testing  tools.  These  attempts  have  been 
useful  but  not  completely  successful.  This  arose  from  two  factors.  The 
first  is  that  the  IGES  testing  methodology  has  not  stabilized 
sufficiently  to  prove  technical  soundness  and  financial  practicality.  The 
next  reason  is  cost.  Some  of  the  cools  and  approaches  proposed  involved 
levels  of  funding  greatly  exceeding  anticipated  resources. 


8.1.  Available  Software  Tools:  Regardless  of  the  structure  of  the  final 
testing  methodology,  some  tools  are  known  to  be  needed  and  are  currently 
available.  These  are  shown  in  Figure  3.  Briefly,  the  list  includes 
three  different  Syntax  analyzers,  three  different  IGES  viewers  and 
plotting  packages,  an  application  subset  checker,  and  an  IGES  transfer 
forecaster.  In  addition  there  are  some  utilities  including  an  IGES  file 
generator,  a  file  compression  utility,  and  a  public  domain  IGES  editor. 

An  important  addition  to  this  list  is  an  IGES  fils  comparator.  This  cool 
is  derived  from  a  thesis  by  Rainer  Glacz  and  purports  to  compare  two  IGES 
files  for  equality.  The  comparator  tool  is  not  well  known.  The  first 
public  discussion  of  it  was  presented  at  Che  St.  Louis  IGES  meeting. 
Currently  there  are  no  known  U.S.  installations  of  the  product. 


8.2.  Validation  of  Software  Tools:  The  case  of  the  IGES  comparator 
brings  an  important  issue  into  focus.  How  are  software  cools  validated 
for  use  in  IGES  testing.  Though  not  formally  documented,  cool  validation 
is  performed  through  usage  by  Che  IGES/FDES  Methodology  Testing 
Committee.  AC  a  future  time  this  validation  will  be  performed  by  the  SAE 
Verification  Panel  in  conjunction  with  the  IGES  Testing  Project  and  the 
testing  agencies. 

Not  all  cools  will  require  validation.  Certainly  the  IGES  editor  and 
file  compression  do  not.  Those  that  will  require  validation  are  chose 
chat  Judge  aspects  of  the  systems  under  test.  The  most  obvious  Cool  chat 
requires  validation  is  Che  syntax  checker.  All  files  produced  from  a 
vendors  preprocessor  will  be  sent  through  the  IDA  analyzer  or  the  IGES-QC 
checker.  These  software  packages  must  be  correct.  The  IGES  comparator 
will  require  validation. 

Its  Job  will  be  to  compare  IGES  file  input  to  IGES  file  output.  A 
software  Cool  error  would  seriously  distort  the  testing  results. 
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8.3.  Desired  Tools  Do  Not  Yet  Exist:  Ic  Is  enclclpaced  chac  a  fully 
operaclonal  testing  program  will  need  the  following,  additional  software 
tools. 

o  A  full  screen  IGES  editor  that  Is  sensitive  to  the  construction 
details  of  IGES  files.  The  current  NBS  IGES  editor  Is  useful  but 
not  practical  for  routine  operations. 

o  A  test  case  selector  that  extracts  IGES  test  eases  based  on 
vendor  claims. 

o  A  test  case  generator  that  can  extract  vendor  claim  Information 
and  build  valid  IGES  test  cases  from  component  parts .  The  tool 
should  operate  automatically  with  little  human  Intervention. 

o  A  test  reporting  system  capable  of  guiding  the  test  team  through 
the  test  plan  and  logging  the  results  of  the  test. 
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Currently  Available  ICES  Software  Tools 


Program  Type 

Name 

Source 

Type 

Plotting  ICES  Files 

BASEVIEW 

IGESVIEV 

ICES  View 

Digital  Equipment  Co. 

IGES  Data  Analysis  Co. 

Loye  and  Associates 

C 

C 

C 

ICES  Syntax  Checkers 

Verifier 

ICES  QC 

ICES  Check 

IGES  Data  Analysis  Co. 

Leeds  CADETC 

Loye  and  Associates 

C 

c 

c 

Application  Subset 
Conformance 

ICES  Subset 

Loye  and  Associates 

c 

ICES  Transfer 
Forecaster 

LUDriTE 

Leeds  CADETC 

c 

ICES  File  Comparator 

IMDES 

Rainer  Glatz 

c 

File  Compressors 

COMPRESS 

Data  Compress 

National  Bureau  of  Standards 
Signuffl  Microsystems 

P 

p 

ICES  Editor 

IGES  EDITOR 

National  Bureau  of  Standards 

p 

FILIGREE 

Interactive  Design  Consult 

c 

ICES  File  Generator 

LUIGI 

Leeds  CADETC 

c 

C  =  Conmercial  Product 
P  s  Public  Domain  Product 


Figure  3. 
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Appendix  A.  Verlflcaclon  Tesclng  of  IGES  Processors 
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Appendix  R. 


Test  Cases  for  QuicksCart  Jr. 


This  appendix  concalns  the  ICES  file  listings  for  the  test  cases  used  in 
the  Qulckstart  Jr.  testing.  Tiie  test  cases  are  for: 


Circular  Arc  100 
Line  110 
Angular  Dimension  202 
General  Note  212 
Subfigure  Definition  308 


Appendix  C 
Test  Results  File 

The  following  naterlal  was  collected  during  the  verification  test  of  the 
Autotroll  S7000  CAD  system.  The  methodology  used  was  that  described  by 
the  "Qulckstart"  and  "Qulckstart  Jr"  Implementation  schemes.  The  system 
under  test  is  owned  by  the  Engineering  CAD/CAM  group  at  NBS.  The 
verification  forms  and  Instructions  are  contained  In  Appendix  A. 

Appendix  B  contains  the  test  cases  and  their  plots. 

The  following  is  a  listing  of  the  packets  of  Information  contained  in 
this  appendix. 

o  The  packet  delivered  to  the  testing  agency  containing  a 
Verification  Request  Form  and  the  vendor  claims. 

o  Information  filled  In  by  the  testing  agency:  The  Test  Results 

File  cover  sheet,  Test  Plan  Specification,  Verification  Test  Log, 
Test  Incident  Reports,  and  the  Pre  and  Postprocessor  Entity 
Results  Forms. 

o  Volunteer  Entity  Test  with  plots, 
o  System  printouts  from  the  circular  arc  tests 

o  System  printouts  from  the  line  test 

o  System  printouts  from  the  angular  dimension  test 

o  System  printouts  from  the  general  note  test 

o  System  printouts  from  the  subfigure  definition  test 

o  Prototype  of  the  SAE  Summary  Test  Report 
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Appendix  0  contains  the  exercise  given  to  members  of  the  IGES/PDES 
Testing  Project.  The  package  Is  not  replicated  In  Its  entirety  because 
most  of  the  material  Is  Included  In  other  appendices  in  this  report.  The 
specified  material  can  be  found  as  follows: 

Appendix  A  -  Verification  procedures  and  forms 

Appendix  B  -  Test  cases  and  plots 

Appendix  C  -  Examples  of  the  procedures  on  a  real  system 
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Verlfieaclon  Testing  of  ICES  Processors 
Interim  Verification  Methodology 


A.l.  Introduction 


The  following  provides  a  detailed  view  of  the  Interim  Verification 
Testing  Methodology.  Two  related  ideas  should  be  kept  in  mind.  First, 
Verification  Testing  works  with  one  translator  at  a  time  and  thus  does 
not  speak  to  the  success  of  end-to-end  data  transfer  in  a  users' 
environment.  System- to-system  data  transfer  capability  is  the  concetm  of 
Application  Validation  and  Acceptance  Testing  described  in  "Testing 
Methodology  of  IGES  Translators  and  ICES  Formatted  Data  Files”. 
Verification  Testing  is  concerned  with  a  translator's  completeness  and 
correctness  in  terms  of  the  IGES  Specification  and  the  implementor's 
claims  of  such.  Second,  while  functionality,  as  defined  in  this  document, 
is  important  to  data  transfer,  the  concept  is  difficult  to  define  in  the 
context  of  testing  a  single  translator  for  compliance  to  the  IGES 
Specification.  That  is  to  say,  a  vendor  .may  have  several  valid  options 
for  mapping  an  IGES  entity  into  a  native  entity  in  full  compliance  with 
the  IGES  specification.  However,  users  of  the  system  may  experience  data 
loss.  For  example,  a  circle  translating  to  line  segments  may  be 
acceptable  for  a  technical  documentation  system  and  disastrous  for  a 
system  that  generates  NC  cutter  paths.  Consequently,  the  implementors' 
functionality  claims  will  only  be  used  to  assist  in  the  selection  of 
appropriate  test  cases  for  postprocessor  verification. 

The  results  from  a  verification  test  should  provide  enough  information 
about  IGES  translators  so  that  users  and  vendors  can  make  their  own 
functionality  assessment  in  the  context  of  their  applications  and  user 
environments.  It  is  only  at  the  level  of  specific  applications  and 
specific  user  environments  that  unambiguous  fxinctional  assessments  can  be 
made.  Furthermore,  the  presentation  of  the  testing  results  in  the  public 
domain  provides  a  sound  basis  for  application  and  acceptance  testing 
analysis.  This  frees  users  from  the  burden  of  having  to  design  and  run 
their  own  verification  tests. 


A. 2 .  Preprocessor  Verification  Procedure 


The  preprocessor  verification  is  initiated  by  an  implementor  (called  the 
presenter)  filing  a  Verification  Request  Package  with  the  IGES 
Verification  Panel.  The  Verification  Request  Package  will  contain  a  cover 
sheet,  (Form  1),  a  set  of  entity  mapping  forms,  (Forms  8  and  9),  and  any 
necessary  system,  application,  and  user  documentation.  Additionally,  the 
presenter  must  designate  a  knowledgeable  technical  representative  to  be 
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present  ac  the  test  site  for  the  testing  period.  The  company  technical 
representative  is  an  essential  resource  for  Che  testing  team  Co  draw. 

The  Verification  Request  Package  cover  sheet  contains  identifying 
information  about  the  presenter  and  the  processor  to  be  tested.  It  also 
contains  a  checklist  of  the  information  required  to  support  the 
verification  testing.  The  documents  required  will  vary  from  system  to 
system  but  all  documents  submitted  should  be  listed  on  Che  cover  sheet. 

The  Verification  Request  Package  contain  both  preprocessor  and 
postprocessor  Entity  Mapping  Forms  (Form  8  and  Form  9).  These  forms 
contain  an  extensive  listing  of  entities  and  their  various  attributes 
(Note  chat  these  forms  may  not  be  available  in  time  for  release  of 
version  0.4  •  Ed)  that  the  translator  purports  Co  implement.  The  test 
cases  selected  will  be  chosen  to  confirm  the  accuracy  of  these  forms  and 
Che  translators  conformance  to  the  ICES  Specification. 

When  completed,  Che  entire  package  is  sent  to: 

IGES  Verification  Panel 
Society  of  Automotive  Engineers 
400  Commonwealth  Or. 

Warrendale,  Pa.  15096 
Attn:  Gary  Poliak 


After  reviewing  the  Verification  Request  for  completeness,  Che  IGES 
Verification  Panel  will  schedule  the  test  and  select  a  testing  authority. 
Negotiations  between  the  presenter  and  the  SAE  and  its  agents  will 
determine  the  fees  and  location  of  the  test.  Based  on  the  concents  of 
the  Verification  Request  Packet  and  the  IGES  test  case  library  a 
representative  of  the  Verification  Panel  will  create  a  test  plan  of  the 
tests  Co  be  run  and  the  test  cases  to  be  used.  These  are  listed  on  the 
Verification  Test  Plan  Specification,  (Form  2).  The  testing  authority 
then  receives  the  test  plan  and  performs  Che  following  functions: 


Testing  agency  staff,  a  technical  representative  from  the  presenter, 
and  any  observers  (IGES  Verification  Panel  members,  other  vendor 
representatives)  meet,  review  the  test  plan  detailed  on  Form  2,  and 
coordinate  their  activities.  This  group  constitutes  the  Test  Team. 

A  test  log  (Forms  3  and  3a  continuation  sheet)  is  initiated  by  the 
senior  technical  person  from  the  testing  agency.  The  meeting  of  the 
test  team  in  the  preceding  step  is  noted  in  the  test  log.  This  log  is 
CO  be  kept  in  the  format  presented  in  IEEE  Std  829-1983.  The  contents 
of  the  log  are  discussed  later. 

A  current,  certified  test  case  suite,  on  a  suitable  storage  medium 
(ascii,  9  crack,  magnetic  tape  or  5  1/4  inch  floppy  diskette)  for  the 
system  under  test,  is  obtained  from  the  National  Bureau  of  Standards. 
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The  tesc  Ceaa  Inspects  the  herdtfere/softvere  envlroniaent,  including 
the  translator  under  test  and  docmentation,  and  attests  to  the  fact 
that  it  complies  with  that  described  in  Form  1  from  the  application 
package^  This  is  noted  in  the  Test  Log. 

A  folder  is  prepared  to  hold  the  results  of  the  tests  to  be  performed. 
This  folder  is  commonly  referred  to  as  the  'results  file'.  The  first 
item  in  the  results  file  is  the  cover  sheet.  Form  7. 

The  Volunteer  Entity  Test,  described  later  in  this  appendix,  as 
prescribed  in  the  Test  Plan  is  followed  to  construct  a  simple  native 
model  in  the  CAD  system.  The  ICES  file  and  a  listing  of  the  model  is 
next  generated  by  running  the  Preprocessor  according  to  the  system's 
operating  procedures.  A  Tesc  Log  entry  is  made  Co  note  the  start  and 
finish  of  Che  test.  The  IGES  listing  is  placed  in  Che  results  file 
and  identified  by  a  reference  in  Che  Test  Log.  VIhile  the  naming 
convention  for  these  and  ocher  entries  are  not  defined,  they  must  be  a 
unique  English  name/number  combination  written  on  the  paper  copy  and 
in  the  test  log.  Use  a  Tesc  Incident  Report  (FORM  4}  to  doctuaent  any 
operator  input  required  for  this  cask  and  any  error  messages  or 
anomalies  encountered.  Extensive  operator  input  or  error  messages 
should  be  docvunented,  if  possible,  by  a  printout  placed  into  Che  Tesc 
Results  file  and  referenced  by  a  Tesc  Log  entry  or  Test  Incident 
Report. 

Record  in  the  Tesc  Log  the  values  for  Global  Section  System  ID  (Field 
5),  Preprocessor  Version  (Field  6),  and  IGES  Version  (Field  23). 
Compare  these  values  against  chose  obtained  from  the  IGES  files 
supplied  by  Che  presenter  if  any  were  sent  vith  the  vendor  request 
package.  The  Volunteer  entity  test  is  one  of  these  -  Ed.)  Note  any 
discrepancies  between  volunteer  test  results  and  the  vendor-supplied 
files  on  a  Test  Incident  Report.  In  cases  of  extreme  disagreement, 
the  tesc  agency  and  the  presenter  will  make  a  decision  whether  or  not 
to  proceed  with  the  test. 

Record  in  the  Tesc  Log  the  resulting  values  for  Global  Section  Date 
and  Time  of  Creation  (Field  18)  and  Maximum  Coordinate  Value  (Field 
20).  Compare  against  expected  values  and  log  any  discrepancies. 

Rerun  the  Volunteer  Entity  Tesc  for  each  Preprocessor  mode  of 
operation  chat  will  be  used  during  the  test.  Document  the  volunteer 
entities  chat  are  generated  for  each  Preprocessor  mode. 

In  a  similar  manner,  run  each  test  specified  in  the  Tesc  Plan.  Follow 
the  construction  script  given  in  each  test  case  to  generate  a  native 
part  model  in  the  CAD  system.  If  any  step  in  the  script  cannot  be 
accomplished,  note  Che  limitation  and  proceed.  Collect  screen  plots 
of  each  native  part  model  and  put  them  in  Che  results  file.  Compare 
Che  screen  plot  against  Che  test  case  plot  and  note  discrepancies  in  a 
Tesc  Incident  Report.  Include  all  items  in  Che  Test  Results  file  and 
reference  each  item  by  a  Test  Log  or  Test  Incident  Report  entry. 
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Use  the  verification  or  inquiry  capability  of  the  CAD  system  to 
identify  the  entity  content  of  the  native  model.  Record  the  native 
model  entity  content  on  the  Preprocessor  Entity  Results  Form  (Form  5). 

Convert  the  native  part  model  to  an  ICES  file  using  the  system's  ICES 
Preprocessor.  Carefully  collect  and  label  all  printouts  of  operator 
input  and  ICES  file  output.  Collect  a  cosiputer  readable  copy  of  each 
resulting  IGES  file  for  later  analysis.  Include  all  items  in  the  Test 
Results  file  and  reference  each  item  by  a  Test  Log  or  Test  Incident 
Report  entry. 

In  later  analysis  work,  run  all  IGES  files  produced  through  the  IDA 
and  the  IGES-QC  Analyzers.  Include  printouts  in  the  Test  Results 
file.  Record  the  count  of  all  errors  and  warnings.  Subtract  the 
volunteer  entities  from  the  list  of  entities  in  the  file  get  the 
Test  Set  of  entities  generated  by  the  preprocessor  for  each  test  case. 
Document  the  Test  Set  on  the  Preprocessor  Entity  Results  form. 

Analyze  the  Test  Set  as  follows: 


o  Compare  entities  obtained  against  those  expected  for  the 
test  case. 

o  Analyze  Global  Section  against  paragraph  2. 2. 4. 2  of  the 
IGES  Version  3.0  specification  for  the  following: 

Product  ID  from  Sender  (Field  3) 

System  ID  (Field  5) 

Preprocessor  Version  (Field  6) 

o  Analyze  Entity  DE  Section  against  mandatory  fields  and 

permissible  defaults  given  by  Table  2-3  of  the  specification 
and  for  specific  content  given  in  the  individual  test  case. 


A. 3.  Postprocessor  Verification  procedure. 

The  postprocessor  verification  is  initiated  in  the  same  manner  as  a 
preprocessor  test.  An  implementor  (called  the  presenter)  fills  in  and 
sends  a  Verification  Request  Package  to  the  IGES  Verification  Panel.  The 
Verification  Request  Package  will  contain  a  cover  sheet,  (Form  1),  a  set 
of  entity  mapping  forms,  (Forms  8  and  9),  and  any  necessary  system, 
application,  and  user  documentation.  Additionally,  the  presenter  must 
designate  a  knowledgeable  technical  representative  to  go  to  the  test 
site  for  the  testing  period.  The  company  technical  representative  is  an 
essential  and  necessary  resource  for  the  testing  team  to  draw  upon. 

The  Verification  Request  Package  cover  sheet  contains  identifying 
information  about  the  presenter  and  the  processor  to  be  tested.  It  also 
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contains  a  checklist  for  the  infomation  required  to  support  the 
verification  testing.  The  docximents  required  will  vary  from  system  to 
system  but  all  documents  submitted  should  be  listed  on  the  cover  sheet. 


The  Verification  Request  Package  contain  both  preprocessor  and 
postprocessor  Entity  Mapping  Forms  (Form  8  and  Form  9) .  These  forms 
contain  an  extensive  listing  of  entities  and  their  various  attributes 
(Note  that  these  forms  may  not  be  available  in  time  for  release  of 
version  0.4  •  Ed}  that  the  translator  purports  to  implement.  The  test 
cases  selected  will  be  chosen  to  confirm  the  accuracy  of  these  forms  and 
Che  translators  conformance  to  the  ICES  Specification. 

Vhen  completed.  Che  entire  package  is  sent  to: 

IGES  Verification  Panel 
Society  of  Automotive  Engineers 
400  Commonwealth  Or. 

Warrendale,  Pa.  15096 
Attn:  Gary  Poliak 


After  reviewing  the  Verification  Request  for  completeness,  the  IGES 
Verification  Panel  will  schedule  the  test  and  select  a  testing  authority. 
Negotiations  between  the  presenter  and  the  SAE  and  its  agents  will 
determine  the  fees  and  location  of  the  test.  Based  on  Che  contents  of  the 
Verification  Request  Packet  and  the  IGES  test  case  library  a 
representative  of  the  Verification  Panel  will  create  a  test  plan  of  the 
tests  to  run  and  the  test  cases  to  use.  These  are  listed  on  the 
Verification  Test  Plan  Specification,  (Form  2).  The  testing  authority 
then  receives  the  test  plan  and  performs  the  following  functions: 


Testing  agency  staff,  a  technical  representative  from  the  presenter, 
and  any  observers  (IGES  Verification  Panel  members,  other  vendor 
representatives)  meet,  review  the  test  plan  detailed  on  Form  2,  and 
coordinate  their  activities.  This  group  constitutes  the  Test  Team. 

A  test  log  (Forms  3  and  3a  continuation  sheet)  is  initiated  by  the 
senior  technical  person  from  the  testing  agency.  The  meeting  of  the 
test  team  in  the  preceding  step  is  noted  in  the  test  log.  This  log  is 
to  be  kept  in  the  format  presented  in  IEEE  Std  829-1983.  The  contents 
of  the  log  are  discussed  later. 

A  current,  certified  test  case  suite,  on  a  suitable  storage  medium  for 
the  system  under  test,  is  obtained  from  the  National  Bureau  of 
S  tandards . 

The  test  tefun  inspects  the  hardware/software  environment,  including 
the  translator  under  test  and  docximentatlon,  and  attests  to  the  fact 
that  it  complies  with  chat  described  in  Form  1  from  the  application 
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package.  This  is  noted  in  the  Test  Log. 

A  folder  is  prepared  to  hold  the  results  of  the  tests  to  be  performed. 
This  folder  is  cooBionly  referred  to  as  the  'results  file'.  The  first 
item  in  the  results  file  is  the  cover  sheet,  Form  7. 


The  test  ease  suite  (or  as  much  of  it  as  on-line  storage  permits)  is 
loaded  onto  the  system  and  converted  to  the  system's  internal  coding 
in  accordance  with  the  vendor  dociimentation  provided.  A  hard  copy  of 
the  command  sequence  and  responses  to  accomplish  this  will  be  saved  in 
the  test  results  file. 

The  first  test  case  is  now  processed  by  the  translator  in  accordance 
with  the  documentation  provided  with  the  test  case.  If  additional 
information  is  required  from  the  vendor  technical  representative  to 
accomplish  the  translation,  the  exact  additions  will  be  recorded  in  a 
Test  Incident  Report  and  so  noted  in  the  log.  Any  error  messages  or 
other  anomalies  will  also  be  logged. 

The  resulting  part  file  will  then  be  "activated'*  and  displayed.  Again, 
any  error  messages,  etc.,  will  result  in  an  incident  report  and  be 
logged. 

At  this  point,  a  visual  comparison  between  the  screen  display  and  the 
plot  of  the  test  case  furnished  with  the  test  case  documentation  will 
be  made  and  differences  reported.  A  plot  of  the  screen  display  will 
be  made  for  inclusion  in  the  test  results  file. 

Using  all  the  verification  capability  available  in  the  receiving 
system,  the  part  file  is  checked  to  determine  the  entity  mapping  and 
functionality  claims  from  form  9  and  the  results  recorded  on  the 
Postprocessor  Entity  Mapping  Form,  Form  4.  Functionality  will  be 
verified  in  terms  of  geometry,  structure,  and  annotation  per  J. 

Fleming  position  paper  of  7/87  (Again,  this  is  the  fimctionality  issue 
-  Ed) .  Details  of  what  is  to  be  verified  will  be  found  in  the  start 
section  of  the  test  case  under  consideration.  All  verifications  will 
be  supported  with  hard  copy  in  the  test  results  file. 

The  remainder  of  the  testing  will  consist  of  repeating  the  above  steps 
for  each  test  case  in  the  suite.  As  before,  all  steps,  problems,  and 
error  messages  are  recorded  in  the  test  log  and  all  problems  and  error 
messages  result  in  the  generation  of  an  incident  report. 

At  the  completion  of  testing,  the  test  results  file  will  be  forwarded 
to  the  test  team  leader  or  his  designee  for  analysis,  interpretation, 
and  the  preparation  of  the  summary  test  report. 
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A. 4. I.  Test  Results  File. 

There  will  be  a  file  maintained  for  each  test  conducted  under  the  SAE 
Verification  Testing  Program  and  it  will  consist  of  1)  a  cover  sheet 
(Form  7),  2)  a  copy  of  the  application  package  cover  sheet  (Form  1).  3) 
the  test  log  (Forma  3  and  3a),  4)  all  incident  reports  (Form  4),  in 
chronological  order,  each  with  appropriate  hardcopy  supporting 
documentation,  and  S)  all  entity  mapping  forms  (Forms  5  and  6),  again, 
each  with  appropriate  hardcopy  supporting  documentation. 

The  results  file  cover  sheet  (Form  7)  will  contain  the  unique  test 
identification  number  and  the  names  (signatures)  and  affiliations  of  the 
test  team  and  observers.  The  signatures  are  under  a  statement  to  the 
effect  that  those  signing  attest  to  the  fact  that  the  file  contains  all 
of  and  only  those  materials  associated  with  the  particular  test 
identification  number. 

The  application  package  cover  sheet  is  Form  1.  The  purpose  of  having  it 
in  the  results  file  is  to  define  the  hardware/software  environment  in 
which  the  tests  began.  Any  changes  to  that  environment  would  be 
documented  in  the  test  log  and  incident  reports. 

The  test  log  will  follow  IEEE  Std  829-1983.  Form  3  with  Form  3a  as  a 
continuation  sheet,  will  be  used  for  this  purpose.  The  log  will  contain 
the  test  identifier  and  a  prose  description  of  the  test  at  the  top  of  the 
first  page  followed  by  three  columns,  1)  date/time,  2)  event,  and  3) 
incident  report  reference.  Subsequent  pages  will  have  the  test  identifier 
and  the  three  columns.  The  event  entries  will  record  the  who,  what,  and 
whys  of  all  testing  actions.  Where  any  event  results  in  an  incident 
report,  the  incident  report  number  will  be  recorded  in  column  three.  For 
an  example  of  event  entries,  see  Appendix  A  of  IEEE  Std  829-1983. 

The  Test  Incident  Report  (Form  4)  will  also  follow  IEEE  Std  829-1983.  The 
report  will  contain  1)  the  incident  identification  number,  2) 
identification  of  the  translator  (with  version  number)  under  test,  3) 
identification  of  the  test  procedure  guiding  the  test,  4)  specification 
of  the  test  case  resulting  in  the  incident,  5)  reference  to  the  test  log, 
6)  a  detailed  description  of  the  test  incident,  and  7)  the  incident's 
impact  on  the  tests.  The  description  should  include  the  inputs,  expected 
results,  actual  results,  anomalies,  date  and  time,  procedure  step 
number,  environment,  attempts  to  repeat,  testers  and  observers.  Again,  an 
example  of  an  appropriate  incident  report  may  be  found  in  Appendix  A  of 
IEEE  Std  829-1983.  The  incident  reports  should  have  sufficient  detail  to 
be  an  aid  to  implementors  in  locating  and  fixing  translator  problems. 

The  Entity  Mapping  Results  Forms  record  the  results  of  processing  the 
test  cases.  Forms  5  (preprocessor)  and  6  (postprocessor)  have  been 
prepared  for  this  purpose.  The  forms  will  record  the  test  identifier,  the 
translator  identification,  the  ICES  entity  being  tested,  the  test  case 
identifier,  the  resulting  native  entity  or  entities,  a  statement  of  the 
extent  to  which  the  result  matches  vendor  claims,  and  a  functionality 
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statement  in  terms  of  geometry,  structure,  and  annotation.  In  addition, 
there  will  be  space  for  remarks,  explanations,  or  comments  from  members 
of  the  test  team.  Test  incident  reports  generated  as  a  result  of  the 
particular  test  case  should  also  be  recorded. 

A. 4. 2.  The  Stitimerv  Test  Report. 

The  work  of  the  testing  agency  on  a  translator  verification  will  be 
covered  by  a  report  which  accurately,  clearly,  and  unambiguously  presents 
the  test  results  and  all  other  relevant  information.  The  report  will  have 
the  test  results  file  as  an  appendix  but  will  stand  alone  as  a  docioment. 
The  testing  agency  is  responsible  for  the  generation  of  this  document. 

The  summary  report  will  contain  at  least  the  following  information: 

1)  name  and  address  of  the  testing  agency; 

2)  unique  identification  of  the  report  (such  as  a  serial  number) , 
and  of  each  page  of  the  report; 

3)  name  and  address  of  the  presenter/ implementor; 

4)  description  and  identification  of  the  translator  tested; 

5)  date  of  receipt  of  the  translator  test  request  and  the  date(s)  of 
performance  of  the  tests; 

6)  description  and  identification  of  the  hardware/software  test 
environment; 

7)  a  statement  to  the  effect  that  the  test  results  relate  only  to 
the  single  translator  tested  when  used  in  the  specified 
environment;  8)  identification  of  the  test  methodology  and 
procedure  followed; 

9)  a  results  section  containing: 

a)  the  test  cases  used; 

b)  the  test  cases  for  which  expected  results  were  obtained; 

c)  the  test  cases  for  which  expected  results  were  not  obtained; 

d)  test  cases  for  which  results  were  inconclusive; 

e)  the  number  of  "information  only"  tests  run; 

f)  the  number  of  planned  tests  not  run; 

g)  the  total  number  of  tests  run; 
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h)  any  addlclona  to,  deviations  or  exclusions  from  the  test 
case  specifications  that  took  place; 

I)  disclosure  of  any  non-standard  test  method  or  procedure 
used; 

J)  a  test  discrepancy  sumouiry. 

10)  any  disclaimers; 

11}  a  signature  and  title  of  person(s)  accepting  technical 
responsibility  for  the  test  report  and  date  of  Issue; 

12}  a  statement  delineating  reproduction  rights  to  the  report. 


Corrections  or  additions  to  a  test  report  after  Issue  by  the  testing 
agency,  whether  because  of  objections  on  the  part  of  the  Implementor, 
ICES  Verification  Panel  actions,  or  any  other  reason,  shall  be  made  only 
by  a  further  document,  suitably  marked,  e.g. ,  "Supplement  to  Test  Report 
Serial  Number  .  .  .  . "  and  shall  meet  the  relevant  requirements  of  the 
preceding  paragraphs. 

Upon  completion,  the  test  agency  will  forward  a  copy  of  the  test  svuamary 
report  and  the  appended  test  results  file,  via  the  SAE,  to  the  ICES 
Verification  Panel  for  review  and  concurrence.  Upon  completion  of  the 
panel's  review  and  the  addition  of  any  supplements  that  result  from  that 
review,  the  panel  will  prefix  Its  Imprimatur  to  the  document  and  forward 
a  copy  to  the  presenter  for  review  and  comment.  This  action  will  begin 
the  30  day  review  period  in  which  the  vendor  can  take  reply  to  the  test 
results.  After  the  review  period  and  the  addition  of  any  supplements 
required  thereby,  the  test  report  will  be  ready  for  release.  The  final 
report  will  contain: 

1}  The  imprimatur  of  the  ICES  Verification  Panel; 

2}  The  Summary  Test  Report  with  Supplements  to  date; 

3}  The  appended  Test  Results  File. 


A.S.  Volunteer  Entity  Test 


A. 5.1.  Description 


The  objective  of  the  volunteer  entity  test  Is  to  discover  extra  entities 
present  in  the  IGES  file  as  generated  by  an  IGES  preprocessor.  While 
Volunteer  Entity  is  a  term  that  may  have  a  very  broad  meaning,  for  this 
test  plan  we  will  define  Volunteer  Entity  as;  IGES  entity  information 
chat  has  been  added/created  by  the  translator  and  placed  in  Che  directory 
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entry  (D)  and  parameter  data  (P)  section  of  the  IGES  file  that  is  not 
resident  on  the  native  data  file. 


The  test  begins  with  a  simple  set  of  construction  details  that  are  to  be 
executed  on  the  CAD  system  to  be  tested.  The  model  is  then  preprocessed 
to  create  an  IGES  formatted  file.  A  listing  of  this  file  will  then  be 
analyzed. 

Any  additional  entities  contained  in  the  listing  that  have  not  been 
specified  by  the  construction  detail  are  volunteer  entities. 


A. 5. 2.  Running  the  Volunteer  Entity  Test. 

The  test  is  executed  by  performing  the  following  actions: 

o  Create  a  line  between  the  following  coordinates  (1,  1,  1)  and  (3, 
4,  5).  If  points  are  used  to  construct  the  line,  delete  the 
points  from  the  native  data  file  before  processing  the  IGES  file. 

0  Set  line  font  as  solid. 

o  If  system  is  2-D  ignore  Z  values. 

o  Generate  IGES  formatted  file. 

o  Generate  a  paper  copy  of  the  file 

o  Specify  the  CAD  System  and  IGES  Software  products,  their  revision 
level/release,  and  the  hardware  which  generated  the  IGES  file,  on 
the  file  listing  or  on  a  separate  cover  sheet. 


A. 6.  Implementors*  Privileges  and  Obligations. 

It  is  important  to  the  credibility  of  the  Verification  Program  and  the 
IGES  Organization  that  commercial  implementors  represent  their  support  of 
IGES  appropriately.  After  completing  the  verification  process,  an 
implementor  has  the  privilege  of  so  claiming  in  documentation  and 
advertising.  The  following  wording  is  suggested  for  use  by  implementors 
to  designate  their  support  of  the  IGES  work: 


"(Implementor's  name)  supports  the  work  being  done  by  the  IGES 
Organization.  Our  IGES  conforming  translators  (insert  version 
identifications)  have  been  verified  by  (insert  name  of  independent 
testing  agency)  in  accordance  with  the  procedures  established  by  the 
IGES  Organization  Testing  Methodology  Project.  Detailed  test  results 
are  available  on  request  from  the  (  name  of  sponsoring  government 
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agency  )," 


Implementors  have  an  obligation  to  resubmit  their  translators  for 
verification  upon  changes  to  the  software  which  might  materially  affect 
the  product's  verification  status. 

If  In  a  subsequent  use  of  a  verified  translator,  a  user  has  reason  to 
believe  that  the  translator  is  not  working  as  verified,  the  user  should 
notify  the  Chairperson  of  the  ICES  Verification  Panel.  Such  notification 
should  Include  sufficient  information  to  recreate  the  fault.  The  panel 
shall  forward  the  notification  to  the  presenter  for  response,  and  to  the 
test  authority  for  review.  If  the  presenter  does  not  adequately  resolve 
the  problem,  the  verification  for  the  translator  will  be  revoked. 


IGES  Verification  Request 


Company  Name: 

Contact; 

Address: 


Phone;  ( _ ) _ - _  Date: 

Request  for  Verification  of: 

_  Preprocessor  IGES  Specification  Version: 

_  Postprocessor 


Configuration  Information 

CAD  Software: 

Version/Release  ID: 

Release  Date: 

IGES  Processor  Name: 

Version/Release  ID: 

Release  Date: 

Computer  Mfq: 

Model: 

CPU: 

Memory  Size: 

Operating  System: 

Version: 

' 

Supporting  Information 

Postprocessor  Entity  Maps  _ System  Limit  Form 

Preprocessor  Entity  Maps  _  General  Entity  Test 

Processor  Documentation  _ Volunteer  Entity  Test 

Tape  Access  Documentation 

Other  (itemize) 


_ for  SAE  Use  Only _ 

Vendor  Request  Number:  _  . 

Assigned  to:  _  Date: 


Form  I 


Verification  Test  Plan  Specification 


Vendor  Request  Number:  _ 

Vendor  Name;  _ 

Test  Log  Identification  Number; _ 

Test  Cases 


Form  2 


Sheet  oi  _ 

Verification  Test  Log 

Test  Loq  Identification  Number: 

Test  Description: 

Date/Time 

nvn/dd/yy-hhimm  Activities  and  Event  Entries 

Incident  Report 
Reference 

Form  3 


Form  3n 


Test  Incident  Report 


Incident  Identification  Number: 
Test  Log  Identification  Number: 
Description  of  Incident: 


Impact  of  Incident: 


Form  •> 


ShMt _  o( 

Pre-processor  Entity  Results  Form 

Test  Log  Identification  Number:  _ _ 

Native  entity  being  translated:  _ _ _ 

Test  Case  Name:  _ _ 

Entity  or  entities  in  resulting  IGES  file: 


Results  agree  with  vendor  entity  map?  Yes _  No 

Description  of  functionality  retained: 


Incident  Reports  generated: 


Remarks  (with  originator  initials) 


Form  5 


Post-Processor  Entity  Results  Form 


Stim: 


Test  Log  Identilication  Number:  _ 

IGES  entity  being  translated;  _ 

Test  Case  Name:  _ 

Entity  or  entities  in  resulting  data  base: 


Results  agree  with  vendor  entity  map?  Yes _  No 

Description  ot  functionality  retained: 


Incident  Reports  generated; 


Remarks  (with  originator  initials) 


Form  6 


Test  Results  RIe 


Test  Identification  Number: 
Translator  Identification: 


The  Undersigned  certify  that  the  materials  and  records  contained  in  this  file  are  all  those 
and  only  those  associated  with  the  above  identified  translator  test. 


Team  Leader 

Affliliation 

Vendor  Reresentative 

Affliliation 

Observer 

Affliliation 

Form  7 


IGES  Processor  Mapping  Form 
Global  Section  Characteristics 


Field 


Name 


Attribute  |  Supported  Comments 

I  Mark  la«t  cotumn  rf  continuaiien 

Pre  Post  SNiei  is  used 


Preprocessor  Mapping  Form 
Directory  Entry  Characteristics 


Vendor  Request  Number: 


Date: 


Field 


Name 


Structure 


Line  Font 


Attribute 


Name 


Comments 

Pre  j 

Post 

Mark  last  column  if  continuation 
snoot  it  used 

Label 

18 

Subscript 

19 

r<iumuar  Oi  iViuilipie  Ei'iiiiies  ret  Levei  Pennitied: 
Number  of  Multiple  Colors  Per  Level  Permitted:_ 
Total  Number  of  Levels  Permitted: 


Form  8B 


Preprocessor  Mapping  Form 
Directory  Entry  Characteristics 


Number: 


Continuation  Sheet 

Comment 


Form  80 


Preprocessor  Entity  Mapping  Form 


Vendor  Request  Number: 


Vendor  Entity 

IGES  Entity 

ID 

Name 

ID 

Form 

Name 

Appendix  S. 


Test  Cases  for  Quicks tart  Jr. 


This  appendix  contains  the  ICES  file  listings  for  the  test  cases  used  In 
the  qulckstart  jr.  testing.  The  test  cases  are  for: 


Circular  Arc  100 
Line  110 
Angular  Dimension  202 
General  Note  212 
Subfigure  Definition  308 


s 

F  ElOOOOOO.AOl  S 

A  S 

V  IGES  3.0  S 

I  Encicy  Tesc  designed  Co  show  correct  geoaecry  only  vichouC  S 

accrlbuces  such  as  level,  font, and  color.  The  encicy  is  S 

IGES  100,  Form  0--the  circular  arc.  S 

E  Encicy  Form  Type  Counts 

100  0  4S 

P  Visually  verify,  comparing  with  Che  accompanying  plot,  S 

chat  four  circular  arcs  were  generated  as  follows:  S 

A  full  circle  in  solid  line  font  S 

A  270  degree  arc  through  quadrants  II, III,  and  IV  S 

in  solid  line  font  S 

A  90  degree  arc  through  in  quadrant  III  in  solid  S 

line  font  S 

A  180  degree  arc  through  quadrants  II  and  III  in  S 

solid  line  font  S 

Using  Che  system's  verification  commands,  verify  chat:  S 

The  full  circle  is  in  the  Z^IO  plane. is  centered  at  S 

(15,15,10)  and  starts  and  ends  at  (15,5,10  or  S 

degrees.  The  radius  should  be  10.  S 

The  270  degree  arc  is  in  the  Z^-IQ  plane,  is  centered  at  S 

(15,-15,-10),  starts  at  (15, -5, -10  or  90  degrees),  S 

and  ends  at  (25,-15,-10  or  0  degrees).  Its  radius  S 

should  be  10.  S 

The  90  degreee  arc  is  in  the  Z^-IO  pl£me,  is  centered  S 

at  (-45,15,-10),  starts  at  (-55,15,-10  or  180  S 

degrees)  and  ends  at  (-45, -5, -10  or  270  degrees).  S 

Its  radius  should  be  10.  S 

The  180  degree  arc  is  in  the  2=0  plane,  is  centered  S 

at  (-45,-15,0),  starts  at  (-45, -5,0  or  90  degrees),  S 

and  ends  at  (-45,-25,0  or  270  degrees).  Its  radius  S 

should  be  10.  ■  _  S 

R  Post  processing  this  file  should  produce  four  circular  arcs  S 

of  radius  10  located  as  indicated  in  the  P  section  above.  S 

The  360  degree  arc  may  be  mapped  to  a  circle  on  some  systems.  S 

C  To  prepare  this  test  case  for  a  preprocessor  test,  create  S 

a  geometric  data  base  on  the  system  hosting  the  translator  S 

according  to  the  following  script  (Level,  font,  and  color  S 

are  default) :  S 

1)  Construct  a  circular  arc  of  radius  10  in  the  2=10  S 

plane,  centered  at  (15,15,10),  starting  and  ending  S 

at  (15,5,10  or  90  degrees).  Some  systems  may  S 

require  this  to  be  constructed  as  a  ’circle”.  S 

2)  Construct  a  circular  arc  of  radius  10  in  the  2=-10  S 

plane,  centered  at  (15,-15,-10),  starting  at  S 

(15. -5,-10  or  90  degrees),  and  ending  at  (25,-15,-10  or  S 

0  degrees) .  S 
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3)  Construct  a  circular  arc  of  radius  lOln  the  Z=10 
plane,  centered  at  (-45,15,10),  starting  at  (-55,15,10 
or  180  degree's),  and  ending  at  (-45,5,10  or  270 
degrees) . 

4)  Construct  a  circular  arc  of  radius  10  In  the  Z=0 
plane,  centered  at  (-45,-15,0),  starting  at 

(-45, -5,0  or  90  degrees),  and  ending  at  (-45,-25,0  or 
270  degrees) . 

5)  Hake  a  plot  of  the  resulting  graphics  aodel  and 
compare  It  with  the  plot  accompanying  the  test  case 

N  WARNING:  This  file  has  been  accepted  as  a  candidate  test 
file  by  the  Test  Case  Development  Committee  but  It  has 
not  been  approved  as  a  member  of  the  Test  Case  Library. 

0  Not  available 

H  02-Oct-1987  DOR  created  this  file 

L  These  data  were  prepared  In  conjunction  with  work  sponsored 
by  an  agency  of  the  United  States  Government.  Neither 
the  United  States  Government  nor  any  agency  thereof,  nor 
any  of  their  employees,  makes  any  warranty,  express  or 
Implied  or  assumes  any  legal  liability  or  responsibility 
for  the  accuracy,  completeness,  or  usefulness  of  any 
Information,  apparatus,  product,  or  process  disclosed,  or 
represents  that  its  use  would  not  Infringe  privately  oimed 
rights.  Reference  herein  to  any  specific  commercial 
product,  process,  or  service  by  trade  name,  trademark, 
manufacturer,  or  otherwise,  does  not  necessarily  constitute 
or  imply  Its  endorsement,  recommendation,  or  favoring  by 
the  United  States  Government  or  any  agency  thereof. 


, ,8HE1000000, .12HHANDHADE  1 ,0. 3H1 .0, 32,38 ,6 ,38, 15 . 8HE1000000 , 1 .0 . 1 .  G 
4HINCH, 1,0. 001, 13H021987. 074640. 0.0001, 100. 0000, , ,4.0;  G 

100  1  ,  10  0  OOOOOOOOOD 

100  0  0  1  0  CIRCARC  ID 

100  2  1  0.-  0  ^u)nnQfinnQoa 

100  0  0  l  0  CIRCARC  2D 

100  3  10  0  OOOOOOOOOD 

100  0  0  1  0  CIRCARC  3D 

100  4  10  0  OOOOOOOOOD 

100  0  0  1  0  CIRCARC  4D 

100.10.0000,15.0000,15. 0000 ,15. 0000 , 5 . 0000 . 15 . 0000 , 5 . 0000 ;  1 P 

100,-10.0000,15. 0000 ,-15. 0000 ,15. 0000 . - 5 . 0000 , 25 . 0000 ,-15. 0000 ;  3P 

100,10. 0000 , -45 . 0000 , 15 . 0000 , - 55 . 0000 , 15 . 0000 , -45 . 0000 , 5 . 0000 ;  5P 

100,0. 0000 , -45 . 0000 ,-15. 0000 , -45 . 0000 , - 5 . 0000 , -45 . 0000 , -25 . 0000 ;  7P 

S  78G  2D  8P  4  T 


s 

F  El 100000  S 

AOl  S 

V  ICES  3.0  S 

I  The  incenc  is  Co  check  the  LOCATION.  ORIENTATION.  LENGTH  and  END  S 

POINTS  Co  be  within  the  limits  specified  in  field  19  of  the  Global  S 

Section.  The  model  cube  is  X  »  3.7S,  Y  »  4. 875,  Z  >  0.0  .  S 

E  ENTITY  FOFJi  COUNTS 

no  0  2S 

P  Verify  the  following:  S 

*  The  correct  TEST  FILE  has  been  loaded,  S 

*  The  correct  IGES  VERSION  is  being  used,  S 

*  That  a  line  exists  from  (1.5, 1.0, 0.0)  to  (3.75,1.0,0.0)  ,  S 

*  That  a  line  exists  from  (1 . 5 , 1 .0,0.0)  to  (1.5.4.875,0.0)  .  S 

R  The  results  should  be  a  line  2.25  long  and  parallel  to  the  X  axis  at  S 

an  offset  distance  of  Y  »  1.0.  A  second  line  should  be  3.875  long  and  S 

parallel  to  Che  Y  axis  at  an  offset  distance  of  X  >  1.5  .  S 

C  Construct  a  LINE  from  (1.5, 1.0, 0.0)  to  (3.75,1.0,0.0)  and  a  LINE  S 

from  (1.5, 1.0, 0.0)  to  (1.5,4.875,0.0)  .  S 

D  Not  available  S 

H  28-Sept-1987  JLC  wrote  this  test  case.  S 

N  WARNING:  This  file  has  been  accepted  as  a  candidate  test  file  S 

by  the  TEST  CASE  DEVELOPMENT  COMMITTEE  but  it  has  not  been  S 

approved  as  a  member  of  the  TEST  CASE  LIBRARY.  S 

L  This  data  was  prepared  in  conjunction  with  work  sponsored  S 

by  an  agency  of  the  United  States  Government.  Neither  S 

the  United  States  Government  nor  any  agency  thereof,  nor  S 

any  of  their  employees,  makes  any  warranty,  express  or  S 

implied  or  assumes  any  legal  liability  or  responsibility  S 

for  the  accuracy,  completeness,  or  usefulness  of  any  S 

information,  apparatus,  product,  or  process  disclosed,  or  S 

represents  chat  its  use  would  not  infringe  privately  owned  S 

rights.  Reference  herein  to  any  specific  commercial  S 

—  product,  process,  or  service  by  trade  name,  trademark,-  - S 

manufacturer,  or  otherwise,  does  not  necessarily  constitute  S 

or  imply  its  endorsement,  recommendation,  or  favoring  by  S 

the  United  States  Government  or  any  agency  thereof.  S 

S 

IH, ,1H; ,9HLINE  TEST, 12HE1100000. AOl, 12HHANDMADE  1.0,3H1.0,32.38.6,  G 

38,15, ,1.0,1, 4HINCH, 1,0. 030, 13H870928. 161357, l.OE-04, 5. 5E+02,  G 

8HJ  CRUSEY,3HNBS.4.0;  G 

110  1  1100  OOOOOOOOID 

110  0  0  1  0  LINE  X-XD 

110  2  1100  OOOOOOOOID 

no  0  0  1  0  LINE  Y-YD 

110,1.5.1.0,0.0,3.75,1.0.0.0.0.0;  IP 

110.1.5.1.0,0.0.1.5,4.875.0.0,0,0;  3P 

S  38G  3D  iiP  2  T 


F  £2020000. AO 1  S 

A  S 

V  IGES  3.0  S 

I  TEST  CASE  FOR  .ANGULAR  DIMENSION,  ICES  ENTITY  202  WITH  NO  FRILLS  S 

E  ENT  FORM  SUBTYPE  COUNTS 

202  0  0  3S 

212  0  0  3S 

21A  2  0  3S 

106  40  2S 

110  0  2S 

P  Visually  verify,  comparing  the  display  with  the  accompanying  S 

plot,  that  two  lines  were  generated  as  follows:  S 

a  horizontal  line  In  the  Z=0  plane  and  extending  from  S 

(5.68326.3.207)  to  (10.9673,3.207)  and  a  non-horizontal  S 

line  from  (5.68326,3.207)  to  (8.52258,7.6743).  S 

Visually  verify  that  three  angular  dimensions  were  generated  S 

as  follows:  the  text  string, ”57.56*,  In  default  font,  should  S 

be  located  at  (4.214377,5.800756,0) , (8.749586,5.201729,0) ,  and  S 

(11.7294,6.44752,0) ; the  arrow  heads  should  all  be  Inside  the  S 

lines  (or  witness  lines)  and  should  be  .15  long  by  .05  wide.  S 

For  the  first  leaders,  DE7  and  0E9,  the  arrow  heads  should  S 

should  be  at  (9.60104,9.37112)  and  (12.9871,3.207)  with  the  S 

tails  at  (12.0971,6.70102)  and  (12.2762,6.35002).  For  the  S 

second  pair  of  leaders,  DE19  and  DE21,  the  arrow  heads  should  S 

be  at  (9.77381,3.207)  and  (7.87744,6.65927)  with  the  tails  at  S 

(9.30722,5.10423)  and  (9.10058,  5.45523).  For  the  third  leader  S 

"pair”,  DE27  and  DE29,  the  arrow  heads  should  be  at  S 

(8.53908.3.207)  and  (7.21513,5.6172)  with  the  tails  at  S 

(5.23229,6.02699)  and  (8.1863,4,58195).  The  horizontal  witness  S 

line  should  leave  a  .093  gap  to  (11.0609,3.207)  and  extend  S 

to  (13.1138,3.207).  The  other  witness  line  extends  from  S 

(8.57278,7.75329)  to  (9.66903,94781).  All  coordinate  are  inches.  S 

R  The  resulting  data  base/display  should  contain  two  lines,  S 

coincident  at^.theix  left  ends,  with  the  angle  between  them  S 

dimensioned  in  three  different  positions,  first,  above  the  S 

lines,  second,  between  the  lines,  and  third  within  the  angle  S 

formed  by  the  lines  but  beyond  their  end  points.  The  angular  S 

dimension  is  57.56  degrees.  S 

C  To  prepare  this  test  case  for  a  preprocessor  test,  create  a  S 

geometric  data  base  on  the  system  hosting  the  translator  to  be  S 

tested  according  to  the  following  script:  S 

1)  Create  two  lines  with  end  points  as  designated  in  the  S 

P  section  above.  S 

2)  Using  the  host  systems  dimensioning  commands,  place  an  S 

angular  dimension  on  the  lines  with  the  text  located  as  S 

indicated  above.  Use  default  attributes  for  the  dimensions  S 

(text  font,  text  size,  etc.)  The  radii  of  the  leaders  are  S 

2.85582,  4.09055,  and  7.30379.  S 

3)  Make  a  plot  of  the  resulting  graphics  model  and  compare  S 

it  with  Che  plot  accompanying  the  test  case.  S 

N  UARIilNG:  This  file  has  been  accepted  as  a  candidate  test  S 

file  by  the  Test  Case  Development  Committee  but  it  has  S 

not  been  approved  as  a  member  of  the  Test  Case  Library.  S 

D  Not  available  S 


H  03*0ct-1987  DOR  creaced  this  file  S  SS 

L  These  data  were  prepared  In  conjunction  with  work  sponsored  S  56 

by  an  agency  of  Che  United  States  Govemaent.  Neither  the  S  57 

United  States  Govemaent  nor  any  agency  Cherof,  nor  any  of  S  58 

their  eaployees,  aakes  any  warranty,  express  or  lapLled,  or  S  59 

assuaes  any  legal  liability  or  responsibility  for  the  accuracy,  S  60 

coapleteness,  or  \isefulness  of  any  Inforaatlon,  apparatus,  S  61 

product,  or  process  disclosed,  or  represents  chat  Its  use  S  62 

would  not  Infringe  privately  o%med  rights.  Reference  herein  S  63 

CO  any  specific  coaaerclal  product,  process,  or  service  by  S  64 

trade  naae,  cradeaark,  aanufacturer,  or  otherwise,  does  not  S  65 

Imply  Its  endorseaent,  recoaaendatlon,  or  favoring  by  the  S  66 


United  States  Govemaent  or 

any 

agency  thereof. 
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110,5.68326,3 

.207,0.0 

,8.52258,7.6743,0 

.0; 

IP 

1 

110,5.68326,3 

.207,0.0 

,10.9673, 

3.207,0. 

0; 

3P 

2 

212,2,5,0.78, 

0.156,1, 

1.5708,0. 

0,0 

.0.11 

.7294,6. 

44752.0. 

0.5H57. 

.56, 

5P 

3 

1,0.1404,0.156,1002,1 

.5708,0.0 

.0, 

0,12. 

5094,6.44752.0.0. 1H$; 

5P 

4 

214,1,0.15,0. 

05,0.0,9 

.60104,9. 

37112,12 

.0971,6. 

70102; 

7P 

5 

214.1.0.15.0.05,0.0.12.9871,3.207.12.2762.6.35002; 

106.1.3.0.0,8.52257,7.83229.8.57278.7.75329.9.66903.9.4781; 

106.1.3,0.0,10.9673.3.207,11.0609.3.207,13.1138,3.207; 

202.5.11.13.5.68326.3.207.7.30379.7.9; 

212, 2. 5. 0. 78, 0.156, 1.1. 5708, 0.0, 0.0. 8. 74959. 5. 20173. 0.0.5H57. 56, 
1.0. 1404, 0.156. 1002, 1.5708, 0.0. 0.0. 9. 52959, 5. 20173. 0.0,1H$; 
214.1,0.15.0.05,0.0,7.87744,6.65927.9.10058.5.45523; 
214.1.0.15.0.05,0.0,9.77381,3.207.9.30722.5.10423; 
202.17.0,0,5.68326.3.207.4.09055.19.21; 

212, 2, 5. 0. 78, 0.156, 1.1. 5708, 0.0, 0.0. 4. 21438, 5. 80076. 0.0,5H57. 56, 
1.0. 1404, 0.156, 1002, 1.5708, 0.0, 0.0. 4. 99438, 5. 80076, 0.0,1H$; 
214.1,0.15.0.05,0.0.8.53908,3.207.5.23228.6.02699; 
214,1.0.15.0.05,0.0,7.21513.5.6172.8.1863.4.58195; 
202.25.0.0.5.68326.3.207.2.85582.27.29; 
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UP  7 
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23P  14 

25P  15 

2SP  16 

27P  17 

29P  18 

31P  19 

T  1 


s 

F  E2 120000  S 

AOl  S 

V  ICES  3.0  S 

I  Test  Che  General  Note  (Type  212,  Fom  0)  for  all  funccionalicy  S 

with  a  single  Font  Code  FOl.  Funccions  exercised  include:  S 

Text  Height  Vertical  Text  Slant  Angle  Mirroring  S 

Text  Width  Horlz  Text  Rotation  Multi  Line  S 

The  working  cube  for  this  test  extends  froa  S 

X  »  -180  to  X  »  280,  Y  «  -180  to  Y  »  320,  Z  »  0  .  S 

E  Entity  Fora  Type  Counts 

212  0  28S 

P  Verify  the  following:  S 

*  All  character  strings  read  as,  3  MM  TEXT,  10  MM  TEXT  or  20  MM  TEXT  S 

except  for  the  MULTI -LIME  text.  S 

*  A  5  MM  TEXT  string  located  at  (20.0,20.0,0.0),  0  slant  and  S 

string  length  30  aa  .  S 

*  A  10  MM  TEXT  string  located  at  (20.0,40.0,0.0)  0  slant  and  S 

string  length  100  aa  .  S 

*  A  20  MM  TEXT  string  located  at  (20.0,60.0,0.0),  0  slant  angle  and  S 

string  length  200  ma  .  S 

A  7  character  rosette  of  3  MM  TEXT  rotating  each  string  45  degrees  S 
froa  0  thru  360  degrees  for  S 

VERTICAL  text  with  rosette  center  at  (-100.0,200.0,0.0),  S 
HORIZONTAL  text  with  rosette  center  at  (-100.0,-80.0,0.0).  S 

*  A  COMPRESSED  20  MM  TEXT  string  with  0  slant  angle  S 

located  at  (20.0,280.0,0.0)  and  string  length  =  50  aa,  S 

located  at  (20.0,250.0,0.0)  and  string  LENGTH  =  100  aa,  S 

located  at  (20.0,220.0,0.0)  and  string  LENGTH  ^  ISO  aa  .  S 

*  A  SLANTED  20  MM  TEXT  string  with  string  length  >  200  aa  and  S 

45  degree  SLANT  angle  located  at  (20.0,170.0,0.0),  S 

30  degree  SLANT  angle  located  at  (20.0,140.0,0.0),  S 

15  degree  SLANT  angle  located  at  (20.0,110.0,0.0)  .  S 

_*  A  MIRRORED  10  MM  TEXT -itsiag-Located  at  (20.0,40.0,0.0)  and-is  --  S 
mirrored  about  the  Y  axis  at  (-20.0,40.0,0.0)  with  each  string  S 
length  =  100  aa  .  S 

*  A  MIRRORED  20  MM  TEXT  string  located  at  (20.0,-60.0,0.0)  and  is  S 
mirrored  about  the  strings  baseline,  each  string  length  =  200  aa.  S 

*  A  10  MM  MULTI-LINE  text  string  located  at  (20.0,-120.0,0.0),  S 

each  line  starting  at  X  «  20.0  and  aaxiaua  string  length  »  100  aa.  S 

R  The  results  should  be  :  S 

Font  1  characters.  S 

Two  rosettes  of  8  text  strings  showing  horlz  &  vertical  characters.  S 

Two  groups  of  3  20  aa  text  strings  showing  text  width  &  slant  angle. S 

One  10  MM  text  string  showing  vertical  airroring  ,  S 

One  20  MM  text  string  showing  horizontal  airroring  ,  S 

A  siaple  Multi -line  text  string  example  .  S 

C  All  TEXT  input  requested  for  this  test  is  shown  between  "  "DO  NOT  S 

enter  the  QUOTE  symbols  with  the  Text.  Soae  Text  request  a  leading  S 
BLANK  .  S 

Prepare  to  generate  text  strings  as  follows:  S 

Set  text  height  5mm,  aspect  ratio  1.0,  slant  0,  horizontal  text  S 

Generate  a  text  string  reading  "  5  MM  TEXT"  at  X  =  -100,  Y  =  -80  S 

Replicate  7  times  at  43  degree  increments  about  normal  at  given  XY  S 
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Generace  a  text  string  reading  ”  S  MM  TEXT”  at  X  «  20,  Y  «  20 
Set  text  height  Son,  aspect  ratio  1.0,  slant  0,  vertical  text 
Generate  a  text  string  reading  ”  S  MM  TEXT”  at  X  «  >100,  Y  «  200 
Replicate  7  tines  at  43  degree  increments  about  normal  at  given  XY 
Set  text  height  10mm,  aspect  rsLlo  1.0,  slant  0,  horizontal  text 
Generate  a  text  string  reading  ”10  MM  TEXT”  at  X  «  20,  Y  >  40 

Generate  a  text  string  reading  ”10  MM  TEXT”  at  X  «  *20,  Y  «  40 

Mirror  this  string  about  a  vertical  line  through  the  given  XY 
Set  text  height  20nn,  aspect  ratio  1.0,  slant  0,  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT*  at  X  >  20.  Y  «  60 

Generate  a  text  string  reading  ”20  MM  TEXT”  at  X  ■  20,  Y  «  -60 

Mirror  this  string  about  a  horizontal  line  through  the  given  XY 
Set  text  hei^t  20inm,  aspect  ratio  1.0,  slant  15,  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT”  at  X  a  20,  Y  »  110 
Set  text  height  20mm,  aspect  ratio  1.0,  slant  30,  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT”  at  X  «  20,  Y  «  140 
Set  text  height  20mm,  aspect  ratio  1.0,  slant  45.  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT*  at  X  «  20.  Y  «  170 
Set  text  height  20mm,  aspect  ratio  .75.  slant  0,  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT”  at  X  «  20.  Y  «  220 
Set  text  height  20mm,  aspect  ratio  .50.  slant  0.  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT*  at  X  «  20,  Y  «  250 
Set  text  height  20mm,  aspect  ratio  .25,  slant  0,  horizontal  text 
Generate  a  text  string  reading  ”20  MM  TEXT”  at  X  «  20,  Y  »  280 
Set  text  height  10mm,  aspect  ratio  1.0,  slant  0,  horizontal  text 
Generate  a  text  string  at  X  »  20,  Y  »  -120  reading:  ”THIS  IS  A  TEST” 

”0F  MULTIPLE” 
•UNE  TEXT" 

N  WARNING:  This  file  has  been  accepted  as  a  candidate  test 
file  by  the  Test  Case  Development  Committee  but  it  has 
not  been  approved  as  a  member  of  the  Test  Case  Library. 

D  Not  available 

H  30-SEPT-1987  JLC  Wrote  this  TEST  CASE  as  requested  . 

L  This  data  was  prepared  in . conj-unccion  with  work 

by  an  agency  of  the  United  States  Government.  Neither 
the  United  States  Government  nor  any  agency  thereof,  nor 
any  of  their  ei^>loyees,  makes  any  warranty,  express  or 
implied  or  assumes  any  legal  liability  or  responsibility 
for  the  accuracy,  comp'leteness ,  or  usefulness  of  any 
information,  apparatus,  product,  or  process  disclosed,  or 
represents  that  its  use  would  not  infringe  privately  owned 
rights.  Reference  herein  to  any  specific  commercial 
product,  process,  or  service  by  trade  name,  trademark, 
manufacturer,  or  otherwise,  does  not  necessarily  constitute 
or  imply  its  endorsement,  recommendation,  or  favoring  by 
the  United  States  Government  or  any  agency  thereof. 

IH, .1H;,17HGENERAL  NOTE  TEST, 12HE2 120000. AO 1 , 14HTEST  HAND  MADE,3H1.0. 
32,38,6,38.15, .1.0,2, 2HMM, 1.0. 045, 13H870930. 110545, 0.0010, 300, 

8HJ  CRUSEY,3HNBS.4, ; 
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,10H  5  MM  TEXT. 0.0;  IP  1 
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212,1.10.200.0.20.0.1. .0.0, 0.0. 20. 0,60. 0,0.0, 10H20  MM  TEXT. 0.0; 
212, 1.10, 200. 0,20. 0.1. 1.308996939, 0.0, 0.0. 20.0. 110. 0,0.0.10H20  M 
M  TEXT. 0.0; 

212, 1,10, 200. 0.20. 0.1. 1.047197551. 0.0. 0.0, 20.0, 140. 0.0.0.10H20  M 
M  TEXT. 0.0; 

212. 1,10, 200. 0,20. 0.1. 0.785931634, 0.0, 0.0, 20.0, 170. 0,0.0.10H20  M 
M  TEXT, 0,0; 

212.1.10.150.0,20.0.1. .0.0, 0.0. 20. 0,220. 0,0.0, 10H20  MM  TEXT, 0,0; 
212.1.10,100.0.20.0.1. ,0.0, 0,0, 20. 0.250. 0,0.0, 10H20  MM  TEXT. 0.0; 
212,1.10.50.0.20.0,1. .0.0, 0.0. 20. 0.280. 0,0.0, 10H20  MM  TEXT, 0,0; 
212,1,10.200.0,20.0.1. .0.0, 2. 0,20. 0,-60. 0,0.0, 10H20  MM  TEXT. 0,0; 
212.1.10,100.0,10.0,1, .0.0, 1.0. -20.0. +40. 0,0.0. lOHlO  MM  TEXT.O, 
0; 

212.1.10,50.0.5.0.1. .0.0, 0.0. -100. 0,-80. 0,0.0, lOH  5  MM  TEXT. 0.0; 
212,1,10,50.0,5.0,1. .0,785398163, 0,0, -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT, 0,0; 

212,1,10,50.0,5.0,1, ,1.570796328, 0.0. -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT. 0.0; 

212.1.10,50.0,5.0.1. .2. 356194490, 0.0. -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT. 0,0; 

212.1,10,50.0.5.0.1. .3. 141592654, 0.0, -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT. 0.0; 

212.1,10,50.0,5.0.1. .3. 926990817, 0.0, -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT, 0,0; 

212,1.10,50.0,5.0.1, ,4. 712388980, 0.0. -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT, 0,0; 

212.1.10,50.0.5.0.1. ,5. 499787144, 0,0, -100. 0,-80. 0,0.0, lOH  5  MM  T 
EXT. 0.0; 

212,3,14,120.0,10.0,1. .0.0, 0,0, 20. 0,-120. 0,0.0, 14HTHIS  IS  A  TEST 
. 11, 110. 0,10. 0,1,, 0.0, 0,0, 20.0, -135. O.O.O.llHOF  MULTIPLE , 9 , 90 . 0 , 
10.0,1, ,0.0, 0,0, 20. 0.-150. 0,0.0, 9HLINE  TEXT, 0.0; 
212,1,10,50.0,5.0,1, ,0.0, 0.1. -100.0, +200. 0,0.0, lOH  5  MM  TEXT.O, 

0; 

212.1.10,50.0,5.0,1, .0.785398163, 0.1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT, 0,0; 

212.1,10,50.0,5.0,1. ,1.570796328. 0,1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT. 0,0; 

212,1,10,50.0,5.0,1, ,2. 356194490. 0.1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT  ,0,0; 

212,1.10,50.0,5.0,1, ,3. 141592654, 0.1, -100. 0,+200. 0,0.0, lOH  5  MM 
TEXT, 0,0; 

212.1.10,50.0,5.0.1. .3. 926990817, 0.1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT, 0,0; 

212.1.10,50.0,5.0,1, .4. 712388980. 0,1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT, 0.0; 

212,1,10.50.0,5.0,1, ,5. 499787144, 0,1, -100.0, +200. 0,0.0, lOH  5  MM 
TEXT. 0.0; 
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F  E3080000.A01  S 

A  S 

V  IGES  3.0  S 

I  Test  Che  subfigure  definition  (Type  308)  and  Che  subfigure  instance  S 

(Type  408)  encicies.  The  resulting  graphics  model  should  have  the  S 
the  same  positioning,  orientation  and  elements  as  indicated  by  the  S 

plot  and  the  elements  listed  in  Che  PD  section.  All  the  elements  S 

of  Che  subfigure  should  act  as  a  part  of  the  whole  for  rotation,  S 

translation,  moving,  coping  and  scaling.  S 

E  Entity  Form  Type  Counts 

100  3S 

no  4S 

124  IS 

308  IS 

408  IS 

410  IS 

P  Visually  verify  against  the  plot  that  a  smiling  face  is  generated  S 

consisting  of  Che  following  encicies:  S 

Three  circular  arcs  S 

Four  lines  S 

Also  used  to  create  this  file  were:  S 

One  sxibfigure  definition  S 

One  subfigure  instance  S 

One  transformation  matrix  S 

One  view  entity  S 

S 

R  Using  the  system's  verification  commands,  verify  chat:  S 

there  is  only  one  occurance  of  the  subfigure,  with  no  translation  S 
chat  every  element  in  Che  subfigure  rotates  when  the  subfigure  is  S 
rotated  S 

chat  every  element  in  the  sxibfigure  translates  when  Che  subfigure  isS 
translated  S 

chat  every  element  in  the  subfigure  moves  when  the  subfigure  is  S 
moved  S 

chat  every  element  in  the  subfigure  copies  when  the  subfigure  is  S 
copied  S 

chat  every  element  in  the  subfigure  chai.ges  size  when  the  subfigure  S 
scaled  S 

S 

C  To  recreate  Che  figure:  S 

Generate  a  full  circle  with  center  ^  (10,10,0)  and  radius  ^5  S 

(zsO  plane,  counterclockwise  direction,  center  point  (10,10)  S 

start  point  (15,10),  term,  point  (15,10))  S 

Generate  a  full  circle  with  center  ^  (-10,10,0)  and  radius  »  5  S 

(z^O  plane,  counterclockwise  direction,  center  point  (-10,10)5 

start  point  (-5,10),  term,  point  (-5,10))  S 

Generate  a  circular  arc  with  center  =  (0,0,0)  and  radius  =  10  with  S 
a  start  angle  of  180  and  a  terminate  angle  of  360  degrees  S 

(z=0  plane,  counterclockwise  direction,  center  point  (0,0)  S 

start  point  (-10,0),  term,  point  (10,0))  S 

Generate  a  line  from  (20,20,0)  to  (20,-20,0)  S 

Generate  a  line  from  (20,-20,0)  to  (-20,-20,0)  S 

Generate  a  line  from  (-20,-20,0)  to  (-20,20,0)  S 

Generate  a  line  from  (-20,20,0)  to  (20,20,0)  S 
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D  Not  Available  S  53 

H  15-Sepc. -1987  created  S  56 

N  Not  Available  S  57 

L  This  data  was  prepared  in  conjunction  with  work  sponsored  by  an  agencyS  58 

of  the  United  States  Govemnent.  Neither  the  United  States  Governments  59 

nor  any  agency  thereof,  nor  any  of  their  employees,  make  any  warranty, S  60 

express  or  implied  or  assumes  any  legal  liability  or  responsibility  S  61 

for  the  accuracy,  completeness,  or  usefulness  of  any  information,  S  62 

apparatus,  product,  or  process  disclosed,  or  represents  that  its  use  S  63 

would  not  infringe  privately  o%med  rights.  Reference  herein  to  any  S  64 

specific  commercial  product,  process,  or  service  by  trade  name,  S  65 

trademark,  manufacturer,  or  otherwise,  does  not  necessarily  constitutes  66 

or  imply  its  endorsement,  recommendation,  or  favoring  by  the  United  S  67 

States  Government  or  any  agency  thereof.  S  68 

, ,1H1,12H£3080000.A01,4HNONE,  G  1 

16HIGES  VERSION  3.0,16,8,24,8,56,1H2,1.0,1,4HINCH,32767,32.767,13H87  915G  2 

.  92738,0.000001,  ,7HUNKNOUN,17HTEST  CASE  mRARY,4,3; 
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110,20.0,20.0,0.0,20.0,-20.0,0.0; 

110,20.0,-20.0,0.0,-20.0,-20.0,0.0; 

110,-20.0,-20.0,0.0,-20.0,20.0,0.0; 

110,-20.0,20.0,0.0,20.0,20.0,0.0; 

100,0.0,10.0,10.0,15.0,10.0,15.0,10.0; 

100,0.0,-10.0,10.0,-5.0,10.0,-5.0,10.0; 

100,0.0,0.0,0.0,-10.0,0.0.10.0,0.0; 

308.0.12HE3080000.F1G,7.1,3.5,7.9,11,13; 

124.1.0,0.0.0.0,0.0,0.0,1.0.0.0.0.0,0.0,0.0.1.0,0.0: 

410,2,1.0.0,0,0,0.0,0; 

408.15.0.0,0.0.0.0,1.0; 
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Appendix  C 
TesC  Results  File 

The  following  material  was  collected  during  the  verification  test  of  the 
Autotroll  S7000  CAO  system.  The  methodology  used  was  that  described  by 
the  "qulckstart”  and  "quickstart  Jr"  implemantaclon  schemes.  The  system 
under  test  is  otmed  by  the  Engineering  CAD/CAM  gro\ip  at  NBS.  The 
verification  forms  and  instructions  are  contained  in  Appendix  A. 

Appendix  B  contains  the  test  cases  and  their  plots. 

The  following  is  a  listing  of  the  packets  of  information  contained  in 
this  appendix. 

o  The  packet  delivered  to  the  testing  agency  containing  a 
Verification  Request  Form  and  the  vendor  claims. 

o  Information  filled  in  by  the  testing  agency:  The  Test  Results 

File  cover  sheet,  Test  Flan  Specification,  Verification  Test  Log, 
Test  Incident  Reports,  and  the  Pre  and  Postprocessor  Entity 
Results  Forms. 

o  Volvinteer  Entity  Test  with  plots, 
o  System  printouts  from  the  circular  arc  tests 

o  System  printouts  from  the  line  test 

o  System  printouts  from  the  angular  dimension  test 

o  System  printouts  from  the  general  note  test 

o  System  printouts  from  the  subfigure  definition  test 
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IGES  Testing  Project 

October  7.  1987 

An  informative  Exercise  in  Verification  Testing 

and 

Test  Case  Design 

To:  All  interested  parties 

From:  Methodology  Testing  Committee  and  the  NBS 

The  following  packet  of  Information  contains  directions  for  building  an  IGES  test  case  and 
running  an  IGES  Verification  Test.  This  exercise  is  necessary  for  anyone  who  wants  to 
understand  IGES  testing  and  IGES  test  case  development  beyond  a  general  level.  The 
tasks  of  writing  a  test  case  and  defining  a  Verification  Test  are  immutably  bound  together, 
and  accordingly,  presented  together. 

You  will  need  a  copy  of  the  IGES  Testing  Methodology  Document  Version  0.5  and  the 
materials  contained  in  this  packet.  These  include: 

Instructions  for  the  exercise. 

Set  of  Verification  Testing  Forms 
One  Example 
Listing  of  test  cases. 

Plot  of  test  cases 

Extractions  from  IEEE  std  829-1983 

After  completing  the  exercise,  the  results  need  to  be  sent  in  for  compilation,  analysis,  and 
distribution.  Testing  comments  and  results  should  be  sent  to  NBS.  Test  case  comments 
and  results  should  be  sent  to  Julia  Terry. 

IGES  Testing 

National  Bureau  of  Standards 
Sound  A-101 
Gaithersburg,  Md.  20899 


Good  Luck. 

Thomas  Wright.  NBS 


Julia  Terry 

Martin  Marietta  Energy  Systems 
Bldg  9103  MS  4 
PO  Box:  Y 

Oak  Ridge,  Tenn.  37831 


ICES  Testing  Project 

October  7.  1987 


Instruction  for  Verification  Test  and  Test  Case  Design 

Verification  Test:  In  order  to  run  the  Verification  Test  it  is  necessary  to  get  a  copy  of  Testing  Method¬ 
ology  of  IGES  Translators  and  IGES  Formatted  Data  Files,  Version  0.5.  Particular  attention  needs  to 
be  paid  to  chapter  5  on  verification  testing,  chapter  9  on  the  IGES  Verification  Panel,  and  appendix  A 
on  performing  a  verification  test.  The  other  materials  contained  in  this  packet  will  need  to  be  reviewed 
as  well. 

As  you  go  through  this  exercise,  you  will  wear  the  hat  of  each  group  mentioned.  Be  a  CAO  vendor 
when  filling  out  the  preprocessor  and  postprocessor  mapping  forms;  be  the  SAE  when  receiving  the 
forms  and  results:  be  the  testing  agency  when  running  the  test;  and  so  forth.  If  you  have  an  IGES 
verifier  available  to  you  or  have  access  to  one,  use  it  to  analyze  IGES  files.  There  is  a  company  that 
will  analyze  your  files  for  a  fee  that  can  be  used.  If  all  else  fails,  skip  this  step  and  proceed. 

There  are  five  test  cases  available  for  this  test.  These  will  be  available  through  the  IGES  bulletin  board 
and  on  floppy  disk  at  the  St.  Louis  IGES  meeting. 

Keep  track  of  your  questions  and  comments  and  send  them  in  with  your  results.  Comments  without 
results  can  also  be  sent,  but  please  indicate  how  much  of  the  procedures  you  went  through.  These 
comments  are  an  important  part  of  this  alpha  test  cycle. 

As  part  of  the  Testers  Forum  in  St.  Louis,  we  will  try  to  run  a  demonstration  Verification  Test  with  one 
or  more  vendors  of  P.C.  products.  It  is  possible  that  modifications  to  these  instructions  will  occur  at 
that  time. 

Cautions:  1  -  Do  not  try  to  assess  the  functionality  of  the  entity  maps.  This  represents  an  important 
issue  that  will  be  addressed  in  St.  Louis.  An  approach  has  been  developed  that  will  use  a  more 
comprehensive  claim  form  to  get  specific  details  about  each  entity.  Unfortunately  these  forms  will  not 
be  available  to  be  placed  in  this  packet.  In  their  place  will  be  the  old  forms  from  version  0.3  of  the 
testing  document.  An  attempt  will  be  made  to  have  these  forms  available  in  St.  Louis. 

Test  Case  Development:  To  develop  a  test  case,  first  read  Appendix  D,  Guide  to  Developing  IGES 
Test  Cases.  Pay  particular  attention  to  the  documented  Jest  cases  in  this  packet — Usiag.  one  of  these 
cases  as  a  model,  redesign  it  for  the  same  entity  and  test  it  on  a  CAD  system.  Remember  that 
enough  information  must  be  provided  about  the  test  case  to  clearly  determine  its  intent.  This  is 
important  for  preprocessor  scripts  that  may  define  illegal  operations  on  some  systems.  For  example, 
some  systems  with  circle  entities  can  not  accept  360  degree  arcs  as  input.  When  finished,  send  the 
completed  test  case  to  Julia  Terry  for  comment. 

The  second  part  of  the  exercise  involves  modifying  or  extending  the  collection  of  candidate  test  cases. 
When  comments  are  returned,  the  IGES  Test  Case  Committee  will  assign  a  test  case  to  be  modified  or 
a  test  case  to  be  developed.  Complete  the  assignment  and  return  it  to  Julia  Terry. 

Cautions:  There  is  a  proposal  to  change  the  definition  of  the  'C  area  of  the  Start  Section  from 
Comments  to  Construction  Scripts.  Comments  will  be  moved  to  the  Note  area.  Also  there  needs  to  be 
emphasis  placed  on  the  intent  of  the  test  case  for  the  M'  area  c*  the  Start  Section. 
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PREFACE 


The  enclosed  material  represents  ideas  and 
concepts  that  are  under  active  discussion  by 
members  of  IGES  Technical  Committees.  Your 
comments  and  ideas  are  solicited  on  these  topics 
and  should  be  addressed  to  the  author. 

It  should  be  noted  that  this  document  has  been 
submitted  for  detailed  review  by  the  IGES 
Organization  and,  as  a  result,  may  undergo 
major  changes  during  technical  review.  In  its 
present  form,  the  document  represents  opinions 
of  the  authors  only  and  should  not  be  taken  as 
representing  any  wider  consensus  such  as  from  an 
IGES  committee. 
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This  document  addresses  the  specification,  purchase  and 
acceptance  testing  of  product  data  in  digital  form.  It  has  been 
prepared  by  the  National  Bureau  of  Standards  under  a  contract 
from  the  Computer  Aided  Logistics  Program  in  the  Department  of 
Defense.  The  document  reports  on  the  IGES  application  subset 
concept,  identifies  several  urgently  needed  subsets,  itemizes  the 
required  technical  content  of  any  subset,  and  gives  several 
examples  of  draft  application  subset  documents. 

It  is  intended  that  this  report  be  reviewed  widely  by  the 
Department  of  Defense,  by  its  industrial  contractors,  by 
committees  of  the  IGES  Organization  and  by  interested  professional 
associations.  While  the  document  has  been  prepared  for  DOD  use, 
the  information  is  generic  and  usefull  for  by  all  parties 
involved  with  the  transfer  of  digital  product  data  files. 

Suggestions  for  additions  and  corrections  to  this  document  should 
be  sent  to  Mr.  Bradford  Smith,  AlOl  Sound  Building,  National 
Bureau  of  Standards,  Gaithersburg,  MD  20899 
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1.0  SCOPE  AND  PURPOSE 


This  document  has  been  prepared  for  the  Department  of  Defense 
program  on  Computer  Aided  Logistics.  The  report  addresses 
mechanisms  for  incorporating  the  exchange  of  digital  product  data 
into  the  normal  procurement  and  business  operations  of  the  DOD. 
Requirements  are  given  for  the  specification,  purchase  and 
acceptance  testing  of  product  data  in  digital  form.  The  document 
calls  for  the  use  of  application  subsets  of  the  Initial  Graphics 
Exchange  Specification  (IGES) . 

The  report  defines  the  general  content  and  use  of  an  IGES 
application  subset  and  presents  the  rationale  for  technical 
choices  made.  Present  use  in  government  and  industry  is 
documented,  and  several  urgently  needed  subsets  are  specifically 
identified.  The  report  itemizes  the  required  technical  content  of 
any  subset,  enumerates  several  application  subsets  for  future 
development,  and  presents  draft  application  subsets  for  Technical 
Illustrations,  2-D  Engineering  Drawings  and  Electrical  Printed 
Wiring  Boards. 

Finally,  this  document  addresses  the  implementation  of  the 
application  subset  concept.  A  draft  policy  statement  is  given  in 
Appendix  A  as  a  model  for  adoption.  The  policy  addresses  digital 
data  exchange  for  internal  transfer  within  an  organizational 
element,  external  transfer  to  contractors,  acquisition  of  new 
parts/ systems,^  data  transfer  from  design  to  product  support,  and 
archival  storage  of  parts/ assembly  product  data. 

Appendix  B  contains  an  updated  DOD  standard  addressing  the  use  of 
digital  product  data.  It  generalizes  the  earlier  Air  Force  work 
on  MIL-STD  1840  which  was  primarily  concerned  with  exchange  of 
technical  documentation  in  digital  form.  The  standard  calls  for 
the  use  of  SGML,  IGES,  CGM  and  CCITT  for  technical  documentation 
and  IGES,  CGM  and  CCITT  for  2-D  engineering  drawings.  Other 
product  data  is  specified  to  use  the  existing  IGES  standard  and 
the  evolving  standards  PDES,  EDIF  and  VHDL.  Where  IGES  or  SGML 
is  specified,  a  reference  is  made  to  a  separate  DOD  specification. 

Appendix  C  contains  the  recommended  draft  DOD  Specification  for 
IGES  Application  Subsets.  The  document  identifies  the  general 
content  for  any  subset  and  specifically  gives  the  requirements 
for  three  initial  subsets;  Technical  Illustrations,  2-D  Engineering 
Drawings  and  Electronic  Printed  Wiring  Boards.  More  application 
subsets  are  expected  to  be  added  in  the  future. 
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2.0  BACKGROUND 


2 . 1  Importance  to  CALS 

The  objective  of  the  CALS  program  in  digital  product  data  is  the 
effective  exchange  of  data  throughout  the  life  cycle  of  weapons 
systems  development  and  deployment  through  the  use  of  computer 
readable  datasets  describing  the  systems,  their  individual  piece 
parts  and  their  product  support  data.  A  central  issue  here  is 
the  technology  of  digital  representation  of  product  data  in  its 
many  forms  of  illustrations,  drawings,  3-D  wire  frame  models, 
surfaced  models,  solids  models  and  complete  product  models. 

The  NBS  CALS  Program  in  product  data  exchange  addresses 

the  exchange,  archiving  and  future  use  by  DOD  of  digital  product 

data.  Major  thrusts  are: 

development  of  a  comprehensive  program  of  testing  and 
evaluation 

identification  and  solution  of  problems  encountered  in 
intersystem  data  exchange 

research  into  the  unique  rec[uirements  for  long-term 
archiving 

development  of  software  tools  to  assist  users  in  making 
routine  production  use  of  digital  product  data 

continued  development  of  new  applications  capability 

validation  of  new  applications  areas 

developmental  work  for  complete  product  model  data. 


Throughout  the  DOD  and  its  partners  in  industry,  an  increasingly 
larger  number  of  computer  aided  design  systems  are  being  used  in 
all  phases  of  design,  analysis,  manufacture  and  test  of  weapons 
products.  Over  a  hundred  vendors  offer  these  CAD  systems.  And 
it  is  natural  that  different  DOD  activities  or  different 
companies  would  choose  different  vendor  systems  to  meet  their 
varying  needs.  Hence,  there  is  a  requirement  in  the  normal 
course  of  business  to  be  able  to  exchange  the  digital  part  models 
that  are  developed  on  one  system  to  be  used  on  another  system. 

Estimated  at  $4.3  billion  in  gross  sales  for  1986,  the  CAD 
industry  is  standing  quickly,  and  the  capabilities  of  CAD 
systems  are  similarly  changing.  But  the  need  for  part  model 
exchange  among  these  systems  has  not  diminished.  Rather,  with 
over  10,000  new  CAD  systems  being  sold  each  month,  portability  of 
data  is  even  more  important  to  the  DOD  and  its  contractors  each 
d3y.  The  exchange  of  digital  product  models  is  expected  to 
become  as  commonplace  in  the  1990 's  as  the  exchange  of  paper- 
based  engineering  drawings  is  today. 
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It  is  essential  for  CALS  to  be  able  to  fully  utilize  these 
automation  resources  both  at  contractor  and  subcontractor 
facilities  as  well  as  inhouse  for  design  review,  second  sourcing, 
overhaul  planning  and  spare  part  production.  Digital  product  data 
exchange  plays  a  key  role  in  each  of  these  areas. 


2.2  Digital  Product  Data 

Two  terms  will  be  used;  product  definition  data  and  product  data. 
Product  Definition  Data  (PDD)  denotes  the  totality  of  data 
elements  to  completely  define  the  product.  Product  definition 
data  includes  the  geometry,  topology,  relationships,  tolerances, 
attributes  and  features  necessary  to  completely  define  a 
component  part  or  an  assembly  of  parts  for  the  purposes  of 
design,  analysis,  manufacture,  test,  inspection.  Very  little,  if 
any,  process  data  is  included,  with  the  exception  being  reference 
to  a  process  standard  (MILSTD)  or  reference  to  a  procedure  which 
results  in  a  product  condition  that  is  not  easily  specified, 
e.g.,  heat  treating  for  1  hour  at  320  degrees.  The  product 
definition  is  expected  to  be  sufficiently  complete  as  to  enable 
the  generation  of  all  downstream  process  data. 

Product  Data  is  more  broadly  defined  than  Product  Definition 
Data.  Product  data  includes  all  of  the  product  definition  data 
plus  a  larger  class  of  data  elements  necessary  to  fully  support 
the  product  for  all  applications  over  its  expected  life  cycle. 


2.3  Life  Cycle  Use 

Indicative  of  this  larger  class  of  product  data  are  engineering 
analysis  models  or  results  and  illustrations  of  the  product  to  be 
used  in  documentation  regarding  operation,  maintenance  and 
engineering  change  control.  Product  data  spans  the  entire  range 
of  disiplines  from  conceptual  design  and  engineering  analysis  to 
manufacturing  planning,  production,  test,  inspection  and 
deployment.  Data  packages  are  expected  to  go  through  repeated 
exchanges  between  primes,  subs,  government  project  managers,  test 
labs,  and  consultants. 


2.4  Product  Data  as  a  Resource 

The  CALS  Program  requires  the  ability  to  deal  with  digital 
product  data  for  four  generic  applications: 

Internal  transfer  of  product  data  among  DOD  components 

The  acquisition  of  new  manufactured  parts/systems 

Data  transfer  fom  Design  systems  to  Product  Support  systems 

Archival  storage  of  parts/assembly  infoirmation 
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Numerous  internal  transfers  of  product  models  are  found  in  R&D, 
prototype  design,  overhaul  and  retrofit  planning,  and  each  is  a 
candidate  for  digital  exchange  in  the  immediate  future. 

Digital  product  data  is  becoming  an  important  consideration  in 
DOD's  contractual  relationship  for  purchase  of  manufactured 
parts,  assemblies  or  whole  systems.  Considerable  work  is 
evolving  in  the  area  of  electronic  publication  and  digital 
exchange  of  technical  documentation.  HIL-STD  1840  is  being 
coordinated  for  DOD-wide  approval  and  makes  use  of  a  subset  of 
IGES  for  the  exchange  of  the  illustrations  in  a  document.  This 
is  thought  to  be  quite  appropriate  since  many  of  these 
illustrations  are  derived  directly  from  the  3-D  CAD  product 
model . 

DOD  has  significant  investments  in  data  archives  necessary  to 
support  its  deployed  forces.  Presently  this  data  consists  of 
millions  of  drawings  stored  in  data  repositories,  but  many 
agencies  are  beginning  to  address  the  problem  of  long-term 
archiving  of  digital  product  data. 

The  economic  significance  of  digital  product  data  is  easily  seen 
from  these  examples.  Efficiency,  accuracy  and  leadtime 
improvements  are  all  substantially  enhanced  through  the  use  of 
CAD  and  CAM  technology  made  possible  by  the  sharing  of  product 
data.  The  CALS  Program  addresses  this  importance  and  is  expected 
to  produce  deliverables  of  use  by  all  of  US  industry. 
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3 . 0  APPLICATIONS  SUBSETS 


Even  with  the  great  variety  of  CAD  systems  in  the  marketplace 
today,  no  one  system  has  the  depth  and  breadth  of  capability  to  be 
able  to  satisfy  the  needs  of  all  users.  Hence,  an  organization 
tends  to  purchase  a  variety  of  CAD  systems,  each  one  thought  to  be 
best  suited  for  its  intended  application.  Data  must  be 
transferred  among  these  business  entities  at  major  milestones  of  a 
project  -  design  to  engineering,  manufacturing  to  inspection, 
prime  to  subcontractor  or  vendor  to  customer.  When  IGES  is  used 
for  the  exchange,  a  range  of  entities  are  needed  to  convey  the 
application's  information  content.  This  list  of  entities,  a 
subset  of  the  IGES  entity  list,  becomes  of  priority  importance  to 
the  successful  exchange  of  the  application. 

3.1  Definition  and  Importance 

The  range  of  applications  for  digital  product  data  is  extremely 
large.  Missile  nose  cone  geometries,  tank  tread  designs, 
footware  sole  pattern  molds,  machining  geometries,  technical 
illustrations  and  architectural  floor  plans  each  have  their  own 
requirements  for  data  content  and  organization.  Some 
applications  like  drawings  make  use  of  simple  modeling  techniques 
like  wireframe  geometry  while  more  sophisticated  applications 
like  tank  vulnerability  analyses  require  a  solids  modeling 
approach. 

Each  of  these  applications  areas  has  different  requirements  for 
the  data  needed  to  describe  the  product  model.  The  first  step  in 
specifying  how  an  applications  area  can  exchange  its  product 
description  as  a  digital  dataset  is  to  carefully  define  the 
information  content  to  be  transmitted.  The  second  step  is  to 
specify  how  this  information  is  mapped  unambiguously  into 
each  IGES  entity.  The  resulting  list  of  IGES  entities  and  their 
meaning  in  the  context  of  the  application  forms  what  is  termed 
the  application  subset. 

An  application  subset  of  IGES  can  then  be  defined  as  a  set  of 
specific  IGES  entity  types  which  are  used  to  completely  and 
unambiguously  represent  the  information  requirements  of  the 
product  for  the  named  application  purpose. 


3.2  Present  Use  of  Applications  Subsets 

Application  sxibsets  are  a  natural  way  of  organizing  the 
informational  needs  for  product  data  transfer  and  are  being  used 
already  by  several  companies  and  government  projects.  Among 
these  are  CAD  system  procurement  specifications  from  the  Naval 
Sea  Systems  Command  and  from  Hughes  Aircraft,  the  Boeing  TOP 
Technical  and  Office  Protocols  specification  for  product  data 
exchange,  and  the  draft  Military  Standard  1840  for  Automated 
Interchange  of  Technical  Information. 
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The  impending  Navy  procurement  of  CAD  workstations  recognizes 
that  there  are  five  major  application  areas  to  be  addressed  - 
mechanical  design,  aeronautical  design,  architectural  engineering, 
electrical/electronic  design  and  technical  publications.  It  is 
felt  that  no  one  vendor  system  can  effectively  meet  the  Navy 
specifications  in  all  areas.  Hence,  the  Navy  strategy  is  to 
allow  multiple  vendor  awards  and  require  IGES  for  internal 
transfer  of  product  data  among  the  dissimilar  CAD  systems. 

Because  it  is  unrealistic  to  require  each  vendor  to  suppoxrt  all 
IGES  entity  types,  application  stibsets  of  IGES  will  be  specified. 
Conformance  to  Version  3.0  is  retired.  Conformance  to  future 
versions  of  IGES  are  called  for  within  six  months  of  publication. 

The  Hughes  Aircraft  Company  makes  use  of  multiple  CAD  systems  in 
all  phases  of  their  mechanical  design,  electrical  design, 
engineering  and  manufacturing  processes.  To  be  able  to  make  use 
of  the  best  tool  for  each  job,  they  have  stressed  the  need  for 
digital  data  exchange  through  IGES  entity  subsets  as  mandatory 
requirements  of  their  CAD  system  procurements.  Version  3.0  of 
IGES  is  specified.  Application  sxibsets  have  been  defined  for 
solids  modeling,  mechanical  design/drafting  and  printed  circuit 
boards.  Future  work  will  develop  subsets  for  finite  element 
modeling,  manufacturing  process  planning  and  NC  tool  paths. 

The  TOP  Specifications  are  being  developed  by  an  industry 
consortium  administered  by  the  Boeing  Company  to  address  the 
exchange  of  typical  data  in  the  engineering,  manufacturing  and 
general  office  environments  over  telecommunications  networks.  One 
problem,  of  course,  is  the  identification  of  standard  formats  for 
product  data  description.  TOP  views  product  data  exchange  as 
critical  to  the  successful  implementation  of  an  integrated 
business  strategy.  In  the  TOP  3.0  Specifications,  product  data  is 
to  be  exchanged  via  a  defined  subset  of  IGES  3.0  entity  types  with 
explicit  constraints  on  file  format,  structure  and  content. 

Two  additional  subsets  are  given  in  the  appendices  of  IGES 
Version  3.0  and  Version  4.0  documents.  These  are  the  Process 
Plant  Flowsheets  and  the  3-D  Piping  System  application  subsets. 

The  piping  material  has  been  influenced  by  the  work  of  the  Navy 
Seawolf  Project  (SSN21)  and  has  been  approved  by  the  IGES 
Architectural  Engineering  Committee. 

Table  1  compares  the  IGES  Entity  Type  content  of  the  above 
subsets.  The  application  subsets  listed  across  the  top  have  been 
assigned  acronyms  as: 

MLSTD  MIL-STD  1840  of  11  Sept  1986 

T  PUB  IGES  Tech  Pubs  Application  Guide  -  Draft  Feb  87 

HA/EL  Hughes  Aircraft  Electrical  Subset  -  V  1.5 

ELCAG  IGES  Electrical  Application  Guide  -  Draft  June  86 

SOLID  Hughes  Aircraft  Solid  Modeling  Subset  -  V  1.5 

DES/D  Hughes  Mechanical  Design/Drafting  Subset  -  V  1.5 

TOP  Technical  &  Office  Procedures  -  Draft  Feb  87 

FLOW  Flowsheet  &  Instrumentation  Diagrams  -  IGES  3 . 0  App  C 

PIPE  3-D  Piping  Systems  -  IGES  Version  4.0  Appendix 
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TABLE  1  -  IGES  ENTITY  CONTENT  FOR  SUBSETS 


E 

N 


T 

F 

I 

0 

T 

R 

Y 

M 

ENTITY  NAME 

100 

Circular  Arc 

102 

Composite  Curve 

104 

Conic  Arc  -  General 

104 

1 

Conic  Arc  -  Ellipse 

104 

2 

Conic  Arc  -  Hyperbola 

104 

3 

Conic  Arc  -  Parabola 

106 

1 

Coordinate  Pairs 

106 

2 

Coordinate  Triples 

106 

11 

Linear  Planar  Curve 

106 

12 

Linear  Curve 

106 

13 

Linear  Curve/Vector 

106 

20 

Centerline  Thru  Points 

106 

21 

Centerline  Thru  Centers 

106 

31 

Section  Lines 

106 

40 

Witness  Line 

106 

63 

Simple  Closed  Area 

108 

0 

Unbounded  Plane 

108 

1 

Bounded  Plane 

108 

-1 

Planar  Hole 

110 

Line 

112 

Parametric  Spline  Curve 

114 

Parametric  Spline  Surf 

116 

Point 

118 

0 

Ruled  Surface  -  Eq  Arc 

118 

1 

Ruled  Surface  -  Eq  Param 

120 

Surface  of  Revolution 

122 

Tabulated  Cylinder 

124 

Transformation  Matrix 

125 

0 

Flash  -  Ref  Entity 

125 

1 

Flash  -  Circular 

125 

2 

Flash  -  Rectangle 

125 

3 

Flash  -  Donut 

125 

4 

Flash  -  Canoe 

126 

Rat  B-Spline  Curve 

132 

Connect  Point 

202 

Angular  Dimension 

206 

Diameter  Dimension 

210 

General  Label 

212 

General  Note 

214 

1 

Leader  Arrow  -  Wedge 

214 

2 

Leader  Arrow  -  Triangle 

214 

3 

Leader  Arrow  -  Fill  Tri 

214 

4 

Leader  Arrow  -  None 

214 

5 

Leader  Arrow  -  Circle 

214 

6 

Leader  Arrow  -  Filled  C 

X  =  Supported  on  Input  &  Output 


M  T  H  E  S  D 
L  ALOE  F  P 

SP/CLSTLI 
TUEAI/OOP 
DBLGDDPWE 

xxxxxxxx 

XXXXXX-- 
XX--XXX- 

??--xx?- 
??--xx?- 
??--xx?- 

--R--R-- 

XXXX-R-- 
--XX-R-- 
--XX----- 

-----XX-- 

xxxx----- 

--XXXR?  -  - 

--XXXR?-- 
XXXXXXXXX 
XXR-XXX-- 
----X---- 
XXXXXXX-- 

-XXXXXXXX 

--XX----- 

--XX----- 

--XX----- 

--XX----- 

--XX----- 

XX----X-- 

--XX---XX 

--X--XX-- 

--X--XX-- 

--X--XX-- 

XXXX-XXX- 

--X--X?-- 

--X--X?-- 

--X--X?-- 


R  »  Supported  on  Input  Only 
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X  X 


TABLE  1  - 

IGES  ENTITY  CONTENT  FOR  SUBSETS 

(Continued) 

E 

N 

M 

T 

H 

E 

S 

D 

T 

F 

L 

A 

L 

0 

E 

F 

P 

I 

0 

S 

P 

/ 

C 

L 

S 

T 

L 

I 

T 

R 

T 

U 

E 

A 

I 

/ 

0 

0 

P 

Y 

M 

ENTITY  NAME 

D 

B 

L 

G 

D 

D 

P 

W 

E 

214 

7 

Leader  Arrow  -  Rectangle 

- 

- 

- 

- 

- 

- 

7 

- 

- 

214 

8 

Leader  Arrow  -  Filled  R 

- 

- 

- 

- 

- 

— 

7 

— 

214 

9 

Leader  Arrow  -  Slash 

- 

- 

- 

- 

- 

- 

7 

— 

- 

214 

10 

Leader  Arrow  -  Integral 

- 

- 

- 

- 

- 

— 

7 

- 

- 

214 

11 

Leader  Arrow  -  Open  Tri 

- 

— 

- 

- 

- 

— 

7 

— 

— 

216 

Linear  Dimension 

- 

- 

X 

- 

- 

X 

X 

— 

— 

218 

Ordinate  Dimension 

- 

- 

X 

- 

- 

X 

- 

— 

- 

220 

Point  Dimension 

- 

- 

- 

- 

- 

— 

- 

— 

— 

222 

Radius  Dimension 

- 

- 

X 

- 

- 

X 

X 

- 

— 

228 

General  Symbol 

- 

- 

X 

- 

- 

X 

- 

— 

— 

230 

Sectioned  Area 

X 

X 

- 

- 

- 

X 

— 

— 

— 

302 

Associativity  Def 

- 

- 

X 

X 

- 

— 

- 

— 

- 

308 

Subfigure  Definition 

X 

X 

X 

X 

- 

X 

— 

— 

— 

312 

0 

Text  Template  -  Abs 

— 

- 

X 

X 

— 

— 

— 

X 

— 

312 

1 

Text  Template  -  Rel 

— 

- 

X 

X 

- 

- 

— 

— 

— 

320 

Network  Subfigure  Def 

- 

- 

X 

X 

- 

— 

- 

X 

— 

402 

1 

Group  w  BP  Instance 

Views  Visible  Inst 

- 

- 

X 

— 

R 

R 

— 

— 

402 

3 

- 

- 

- 

- 

X 

- 

- 

- 

- 

402 

4 

Views  Vis,  Color,  LW 

- 

- 

- 

- 

X 

- 

- 

- 

- 

402 

7 

Group  wo  BP  Instance 

- 

- 

X 

- 

X 

X 

- 

- 

- 

402 

9 

Single  Parent  Inst 

- 

- 

X 

- 

X 

R 

- 

— 

402 

18 

Flow  Associativity 

- 

- 

X 

X 

- 

- 

- 

X 

X 

404 

Drawing 

X 

X 

X 

— 

— 

X 

— 

— 

— 

406 

2 

Property  -  Region  Res 

— 

— 

X 

X 

— 

— 

— 

— 

— 

406 

4 

Property  -  Region  Fill 

— 

— 

X 

X 

— 

— 

- 

— 

— 

406 

5 

Property  -  Line  Widen 

— 

- 

- 

X 

- 

— 

- 

— 

- 

406 

6 

Property  -  Drill  Hole 

— 

- 

X 

X 

- 

— 

- 

— 

— 

406 

7 

Property  -  Ref  Desig 

— 

— 

X 

X 

— 

— 

- 

— 

— 

406 

8 

Property  -  Pin  No. 

— 

— 

X 

X 

— 

— 

- 

— 

— 

406 

9 

Property  -  Part  No. 

- 

- 

X 

X 

- 

— 

- 

- 

- 

406 

11 

Property  -  Tabular  Dat 

— 

- 

X 

- 

- 

- 

- 

- 

— 

406 

12 

Property  -  Ext  Ref  FL 

- 

- 

X 

- 

- 

- 

- 

- 

- 

406 

13 

Property  -  Nominal  Size 

- 

- 

- 

- 

- 

- 

- 

X 

7 

406 

14 

Property  -  Line  Spec 

- 

- 

- 

- 

- 

- 

- 

X 

7 

406 

15 

Property  -  Name 

- 

- 

X 

- 

- 

- 

- 

- 

- 

408 

Subfigure  Instance 

X 

X 

X 

X 

- 

X 

- 

- 

- 

410 

View 

X 

X 

X 

- 

X 

X 

- 

- 

- 

412 

Rect  Array  Sub  Inst 

X 

X 

X 

X 

- 

- 

- 

- 

- 

414 

Circ  Array  Sub  Inst 

X 

X 

X 

X 

- 

- 

- 

- 

- 

416 

0 

External  Reference 

- 

- 

- 

- 

- 

- 

- 

X 

X 

416 

1 

External  Reference 

- 

- 

- 

- 

- 

- 

- 

- 

- 

416 

2 

External  Reference 

- 

- 

- 

- 

- 

- 

- 

- 

- 

420 

Network  Sub figure  Inst 

- 

- 

- 

- 

- 

- 

- 

X 

X 

X  *  Supported  on  Input  &  Output 


R  =  Supported  on  Input  Only 
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As  can  be  seen  from  Table  1,  several  inconsistancies  remain  to 
be  resolved  among  the  different  application  subsets: 


1.  MIL-STD  1840  has  chosen  to  allow  only  default  identity 
Transformation  Matrices  while  the  IGES  Tech  Pubs  Subset 
allows  arbitrary  Transformation  Matrices  to  move  entities 
from  Definition  Space  to  Model  Space  position. 

2.  MIL-STD  1840  and  the  IGES  Tech  Pubs  Subset  use  a  simplified 
form  of  Drawing  and  View  entities  to  make  the  illustration 
file  acceptable  to  most  CAD  systems.  The  Hughes  Solid  Subset 
is  missing  the  Drawing  entity. 


3 .  The  IGES  Electrical  Application  Subset  and  the  TOP 

Mechanical  Subset  contain  neither  the  View  nor  the  Drawing 
entities.  This  makes  it  impossible  to  construct  a  part 
model  on  some  CAD  systems. 


4.  The  TOP  Specification  calls  for  an  application  subset  to  be 
implemented  in  accordance  with  a  list  of  IGES  Recommended 
Practices  which  further  specify  the  processing  algorithms  to 
be  used.  These  include: 


1  Delimiter 

2  Witness  Line  Suppression 

4  Transformation  Matrix  Processing 

5  System  ID  Parameter 

7  Maximum  Coordinate  Value 

8  Independent  Witness  Lines 

15  Zero  Radius  Arcs 

16  Translation  Vector 

17  Model  Space  Scale 

19  Independent  and  Dependent  Processing 

20  Back  Pointers  in  View  Associativity 

21  Comments  in  PD  Records 

22  Bounded  Planes 

24  Representation  of  Linear  Strings 


5.  The  TOP  Specification  calls  for  implementation  of  RP  12  on 
Flag  Notes  without  requiring  the  Flag  Note  entity. 

6.  The  TOP  Specification  is  not  specific  as  to  which  Leader 
Arrow  Form  Numbers  are  required. 


7.  MIL-STD  1840  and  the  IGES  Tech  Pubs  Subset  both  call  for 
adherance  to  IGES  Version  3.0  yet  ask  for  Line  Font  5 
(Dotted)  in  Global  Field  4.  This  capability  exists  only  in 
IGES  Version  4.0 


8.  The  Hughes  Aircraft  Specification  for  Electrical  and  for 

Mechanical  Design/ Drafting  requires  three  new  Leader  Arrows 
(2pts,  3pts  and  4pts)  not  in  IGES. 


9 


9. 


The  Hughes  Aircraft  Specification  for  Electrical  and  for 
Mechanical  Design/Drafting  requires  General  Note  Fonts 
1,  1001,  and  1002  to  be  fully  supported  with  Font  0  only 
processed  when  reading  in  an  IGES  file.  No  other  subse' 
requires  these  fonts  to  be  fully  suppoirted,  although  two 
others  restrict  the  value  of  the  PD  Index  to  these  fonts. 


10.  MIL-STD  1840  and  the  IGES  Tech  Pubs  Subset  both  call  for  a  DE 
Field  4,  Line  Font  Pattern,  value  restriction  of  0  for  Entity 
type  414,  Circular  Array  Subfigure  Instance.  But  neither 
subset  places  a  similar  restriction  on  Entity  type  412, 
Rectangular  Array  Subfigure  Instance. 

11.  Only  the  Hughes  Aircraft  Specifications  place  requirements  on 
the  Global  Section  parameters.  Notable  among  these  are: 


Field 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 


Value  Required 

.  Y 

;  Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

N  Default  to  Field  3 
1.0  Y 

1-11  Y 

Y 

Y 
N 

Y 

Y 

Y 

Y 

Y 

1-4  Y 

0-7  N 
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3 . 3  IGES  Siibsets  of  Interest  to  DOD 

The  list  of  application  areas  of  interest  to  the  Department  of 
Defense  is  expected  to  be  quite  long  and  to  grow  with  experience 
as  digital  product  data  exchanges  become  commonplace.  But  a 
controllable  population  is  expected.  Historically,  the  IGES 
Organization  has  worried  about  the  proliferation  of  entity  types 
as  new  application  areas  express  their  requirements.  Fortunately, 
this  has  not  been  found  as  major  a  problem  as  anticipated,  and  the 
same  is  expected  with  application  subsets. 

Presented  here  are  several  subset  definitions  known  to  have  a 
following  in  the  DOD.  Undoubtably,  there  are  others.  And  no 
special  effort  has  been  made  to  eliminate  an  overlap  of 
requirements.  They  are  by  no  means  specific  only  to  DOD  needs 
and  will  benefit  from  industry  collaboration  as  well. 


Technical  Publication  Illustrations  -  The  exchange  of  figures  for 
a  technical  document  requires  2-D  geometry  plus  annotation. 
Emphasis  is  on  visual  clarity  for  human  interpretation. 

Engineering  Drawing  -  The  2-D  Engineering  Drawing  is  presently  the 
baclcbone  of  product  definition.  Information  is  presented  to 
conform  with  certain  standards  of  style  and  content  as  set 
forth  by  ANSI  ¥14.5,  MIL-SPEC 's  and  MIL-STD's.  Exchange 
emphasis  is  on  completeness,  visual  equivalency  and 
functionality  of  the  received  drawing  model. 

Electrical  Printed  Wiring  Boards  -  This  subset  handles  both  the 
physical  description  of  printed  wiring  assemblies  as  well  as 
the  logical  information  describing  connectivity  and  schematic 
representation.  Design,  engineering,  manufacturing,  testing 
and  inspection  processes  are  supported.  Cabling  and 
connectors  can  also  be  modeled. 

Process  Plant  Flowsheets  -  Process  flowsheets  identify  the  process 
streams,  their  direction  and  instrumentation  lines  flowing 
through  a  plant.  They  identify  the  equipment  names  and  the 
positions  on  the  equipment  where  the  lines  connect. 

Properties  can  be  attached  to  the  lines  or  to  the  equipment. 

Mechanical  Design/ Drawing  -  Frequent  exchanges  are  made  of  3-D 
mechanical  pairt  models  along  with  a  drawing  derived  from  the 
model.  Part  geometry  is  given  as  a  3-D  model  in  either 
wireframe  and/or  surfaced  form.  The  drawing  must  be  able  to 
meet  ANSI  ¥14.5  or  MIL-SPEC  requirements.  Data  requirements 
include  those  of  3-D  mechanical  models,  those  of  2-D 
Engineering  Drawings  and  other  entities  which  define  how  the 
views  on  the  drawing  are  derived  from  the  part  model. 

Architectural  Engineering  and  Construction  -  Many  AEC  applications 
exist  and  are  rich  in  non-geometric  data  content.  Progress  is 
being  made  in  Tabular  Data,  Connectivity  and  External  File 
Reference  to  assist  these  future  application  subsets. 
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3-D  Piping  and  Tubing  -  Found  in  buildings,  refineries,  ships  and 
trucks,  piping  and  tubing  systems  direct  fluids  to  various 
pieces  of  equipment.  The  information  content  of  these  systems 
includes  equipment  nomenclature,  connect  nozzles,  connecting 
pipes  and  the  pipe  line  attributes. 

Mechanical  Solid  Modeling  -  Solid  modeling  is  predominently  used 
for  conceptual  design  of  mechanical  devices  and  assemblies. 

The  solid  model  allows  the  user  to  check  for  clearance 
problems,  compute  mass  properties  and  generate  shaded  images 
of  the  product.  Data  generated  in  the  solid  model  application 
is  often  passed  to  other  solid  model  based  applications.  This 
application  svibset  addresses  the  Solid-to-Solid  information 
exchange . 

NC  Data  Generation  -  The  mechanical  part  model  and  the 

manufacturing  process  plan  form  the  input  for  numerical 
control  machining  data  preparation.  Outputs  include  the 
required  fixtures,  the  cutting  tools  and  the  toolpath  control 
data  for  the  selected  machine.  The  input  requirements  for  the 
part  model  are  addressed  by  this  IGES  NC  Data  Generation 
Subset.  They  include  3-D  wireframe  geometry,  3-D  surface 
geometry  and  first  order  continuity  along  part  geometry. 

Finite  Element  Modeling  -  Exchange  between  a  product  design  system 
and  a  product  structural  analysis  system  requires  capability 
to  describe  the  3-D  finite  element  mesh,  the  engineering 
parameters  of  each  finite  element  and  the  nodal  analysis 
results . 


This  list  of  applications  is  far  from  complete  and  will  grow  with 
experience  and  time.  No  priority  order  is  inferred  by  this  list 
although  Technical  Publication  Illustrations  is  becomming  quite 
mature  with  the  coordination  of  MIL-STD  1840  for  DOD-wide  use. 

The  Electrical  PC  Board  subset  represents  years  of  work  by  the 
IGES  Electrical  Committee  and  is  ready  for  prototype  trial. 

Process  Plant  Flowsheet  has  been  reviewed  as  an  appendix  to  IGES 
Version  3.0,  and  3-D  Piping  is  a  recent  product  of  the  IGES  AEC 
Committee  to  appear  in  IGES  4.0  The  Hughes  Aircraft  procurement 
specification  is  the  source  for  the  remaining  subsets  and  has  been 
reviewed  by  knowledgable  staff  and  vendor  implementors. 

Remaining  to  be  done  is  to  poll  the  DOD  community  for  additional 
ideas  on  IGES  application  subsets  and  their  priority  needs.  This 
can  best  be  done  through  the  NSIA  CAZ^  committees,  the  DOD 
Manufacturing  Technology  Advisory  Group,  inhouse  program  managers 
from  all  service  components  concerned  with  each  application,  CALS 
service  contacts  and  members  of  the  IGES  Organization  who  are  in 
the  DOD  or  affected  companies. 
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3 . 4  General  Requirements 

It  is  important  that  the  specification  of  any  application  subset 
be  complete,  precise  and  unambiguous.  Incomplete  translator 
implementations  or  differing  interpretations  of  entity  meaning  will 
degrade  the  quality  or  will  limit  the  quantity  of  information  which 
can  be  exchanged  between  sender  and  receiver.  The  application 
subset  specification  must  be  complete  in  that  it  be  designed  to 
stand  alone  as  a  document  referencable  in  a  legal  contract  for 
deliverables.  It  must  be  precise  so  that  the  accuracy  and 
functionality  of  the  received  data  is  sufficient  to  support  the 
intended  use  of  the  data.  And  the  specification  must  of  course  be 
unambiguous  so  that  application  information  which  was  mapped  into 
IGES  entities  can  be  fully  recovered  without  any  loss  at  the 
receiving  site. 

An  application  subset  is  thought  to  be  a  mechanism  which  will 
substantially  improve  the  completeness  of  data  exchange  in  the 
specified  area  of  use  over  what  can  now  be  transferred.  For  this 
end-to-end  data  exchange  to  happen: 

The  information  to  be  transferred  must  be  identified. 

The  information  must  be  uniquely  mapped  into  IGES  entities. 

The  entities  must  be  exchanged  accurately  and  completely. 

The  receiving  system  must  be  capable  of  processing  each 
entity  in  the  subset. 

The  receiving  system  must  be  capable  of  representing  each 
information  construct. 

The  most  demanding  of  these  steps  is  that  of  identifying  the 
information  content  of  a  prescribed  application  area.  Formal 
modeling  techniques  such  as  IDEFIX,  NIAM  and  EXPRESS  which  are 
being  used  in  the  IGES  Organization  are  certainly  of  help  for 
this. 

Next  the  information  must  be  mapped  into  a  series  of  IGES  entity 
types.  It  is  impoirtant  that  this  mapping  be  unique,  for  if  a 
dashed  line  is  represented  in  any  of  three  different  ways  as  IGES 
now  allows,  a  receiving  CAD  system  must  be  very  intelligent  to 
recognize  they  are  identical. 

This  leads  to  a  restrictive  entity  subset  for  each  application 
area.  No  entities  can  be  used  which  are  not  enumerated  in  the 
application  siibset.  While  it  is  recognized  that  this  places 
burdens  on  the  software  developer  and  on  the  CAD  operator,  no 
other  way  guarantees  the  needed  completeness  of  data  exchange. 

See  Section  5.0  of  this  report. 

A  last  requirement  of  an  application  subset  is  to  properly  limit 
the  range  of  entity  type  numbers  and  their  parameter  values.  The 
entity  descriptions  which  result  are  called  the  application  subset. 
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3.5  Technical  Content  of  an  Application  Subset 

An  application  subset  must  be  sufficiently  precise  and  comprehensive 
in  its  definition  to  serve  as  a  portion  of  a  contract  between  the 
two  parties  of  the  data  exchange.  At  a  miminum,  the  documentation 
requirements  for  an  application  subset  include  the  following: 


SCOPE  -  A  general  introduction  of  the  application  and  the 
discipline  being  served.  Statements  of  purpose  of  the  subset 
and  a  specific  description  of  the  industry  and  range  of 
applications  to  be  served  will  be  given. 

INFORMATION  REQUIREMENTS  and  DATA  FUNCTIONALITY  -  A  detailed 
list  of  what  must  be  transferred  through  the  use  of  the  subset. 
This  could  include  3-D  geometry,  associativity  elements  denoting 
fluid  flows,  view  transforms,  fonts,  and  so  forth.  This  section 
must  be  filled  out  with  considerable  care  because  it  will  serve 
as  the  basis  for  deciding  which  entities  will  be  included  in 
the  IGES  subset. 

IGES  ENTITY  SUBSET  SPECIFICATION  -  The  description  of  the 
entities  to  be  used  for  the  sxibset.  An  optional  section 
describing  why  these  specific  entities  and  not  others  were 
used,  can  go  here.  Limits  on  parameter  range. 

MAPPING  of  INFORMATION  CONTENT  to  IGES  SUBSET  ENTITIES  - 
This  is  the  specification  of  how  the  application  functions  and 
related  information  is  to  be  mapped  into  an  IGES  subset.  As 
an  example  "All  steam  lines  will  be  represented  by  copious 
data  entities  of  Form  3  denoting  x,  y,  and  z  coordinates". 

The  Implementors  of  IGES  translators  will  use  this  section 
as  a  guide  for  designing  their  products. 

DATA  ACCURACY  REQUIREMENTS  -  A  description  of  data 
accuracy  rec[uirements  not  covered  by  the  data  functionality 
section.  Such  items  as  the  minimum  number  significant  digits 
would  be  included  here 

USER  CONVENTIONS  and  DATA  ORGANIZATION  -  A  listing  of  the 
required  usages  not  normally  covered  by  the  IGES  specification. 
An  example  would  be:  "Electrical  details  are  presented  in  level 
4,  plumbing  in  level  5" 

TESTING  REQUIREMENTS  -  A  detailing  of  the  test  cases  used  and 
their  purpose.  The  concept  and  its  implementations  must  be 
tested.  Each  functional  component  should  be  covered  by  one  or 
more  test  cases.  This  section  describes  them  and  the  results. 

EXAMPLES  of  APPLICATION  SUBSET  USE  -  An  instructional  set  of 
examples  showing  typical  use  of  the  subset. 

REFERENCES 
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4.0  TESTING  METHODOLOGY  FOR  APPLICATION  SUBSETS 

The  development  of  IGES  validation  testing  methods  is  one  of  the 
major  projects  of  the  IGES  Organization.  This  section  summarizes 
the  current  efforts  in  testing  methodology,  summarizes  the 
concepts  developed  for  the  program,  and  provides  a  more  detailed 
look  at  how  application  subsets  can  be  tested.  Version  0.3  of  the 
Testing  Methodology  working  paper  is  included  as  an  appendix. 

This  document  is  now  being  coordinated  by  NBS  and  will  be 
substantially  revised  and  expanded  by  March  1987 . 


4 . 1  Testing  Methodology  Concepts 

IGES  Testing  is  concerned  with  developing  and  maintaining  test 
procedures  which  deal  with  verification  testing,  validation  of 
processors  for  specific  application  subsets,  and  application  specific, 
user  performed  acceptance  testing. 

Verification  testing  is  aimed  at  ensuring  that  the  implementor's 
claims  for  entity  mapping  and  functionality  of  translation  are 
accurate.  Validation  testing  is  aimed  at  ensuring  that  application 
subsets  of  IGES  are  treated  in  a  manner  consistent  with  the 
application.  And  acceptance  testing  is  aimed  at  ensuring  that 
particular  IGES  processors  will  work  adequately  in  a  user's 
environment.  The  immediate  goal  of  the  Testing  Methodology 
Committee  is  to  establish  a  verification  program  for  translators. 

Objectives  of  this  testing  are  to  verify  the  correctness  of  the 
implementor's  claims  for  individual  entity  processing,  to  measure 
the  precision  of  data  translation  and  to  assess  the  degree  to 
which  the  functionality  of  the  entities  have  been  maintained. 
Functionality  of  the  results  of  a  translation  is  defined  as  the 
degree  to  which  received  entities  can  be  manipulated  as  if  they 
had  been  generated  on  the  receiving  system. 

There  are  several  major  reasons  why  testing  IGES  processors  is 
necessary.  Both  implementors  and  users  of  the  processors  are 
interested  in  testing.  Implementors  need  a  set  of  widely  accepted  test 
procedures  and  data  in  order  to  ensure  that  their  products  conform  to 
and  adequately  support  entity  subsets  for  a  specific  application  area 
of  the  IGES  standard  (i.e.,  verification  and  validation  testing). 

Users  and  implementors  need  a  set  of  widely  accepted  test  procedures 
to  determine  if  the  processors  in  question  will  adequately  support  the 
user's  data  exchange  requirements  (i.e.,  acceptance  testing).  In 
addition,  users  frequently  desire  advice  on  how  to  construct  test  data 
sets  which  will  accurately  reflect  these  data  exchange 
requirements.  Finally,  since  much  data  exchange,  worth  millions  of 
dollars,  will  be  accomplished  using  IGES  translators,  users  are 
requiring  more  assurance  that  the  data  is  not  being  modified  or  lost 
during  the  exchange  process. 
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The  objective  of  IGES  testing  is  to  expose  flaws  in  the  IGES 
products  (i.e.,  to  show  where  products  do  not  work  as  they 
should) .  In  his  book,  "The  Art  of  Software  Testing"  (MYER79) , 
Glenford  Myers  cites  the  following  basic  principles: 

.  Testing  is  the  process  of  executing  a  program  with  the 
intent  of  finding  errors. 

.  A  good  test  case  is  one  that  has  a  high  probability  of 
detecting  an  as  yet  undiscovered  error. 

.  A  successful  test  case  is  one  that  detects  an  as  yet 
undiscovered  error. 

In  the  context  of  generalized  IGES  translator  testing,  the  test 
cases  developed  will  be  aimed  at  exposing  flaws  in  important 
features  of  the  translators.  A  broad  range  of  test  cases  will  be 
validated  and  thoroughly  documented. 

This  section  has  been  condensed  from  the  working  papers  of 
the  testing  methodology  committees  with  modifications  to 
incorporate  recent  progress  and  to  specificallv  address  the  needs 
of  application  subsets.  The  intent  is  to  Dr-.Vj.ae  a  background  in 
testing  concepts  for  the  reader.  More  detailed  information  can 
be  found  in  the  working  document  ('  £ST86) . 


4.2  Use  of  Entity  Mapping  in  Data, Exchange 

Entity  mapping  can  be  described  as  the  manner  in  which  the 
implementor  of  a  translator  has  defined  the  correspondence  between 
native  entity  forms  (i.e.,  the  entity  form  maintained  within  a  system) 
and  the  IGES  entity  forms  (i.e.,  the  entity  form  contained  in  the  IGES 
Specification) .  For  example,  a  string  of  curve  and  line  segments  on  a 
system  may  be  translated  into  a  Composite  Curve  entity  (Type  102)  by  a 
preprocessor.  This  correspondence  of  a  string  in  the  native  form  to  a 
Composite  Curve  in  the  IGES  form  is  the  preprocessor's  entity  mapping 
for  the  native  string  entity.  Similarly,  a  postprocessor  may  translate 
a  Copious  Data  entity  (Type  106)  into  a  3-D  line  entity  on  the 
receiving  system  under  some  circximstances .  Thus,  the  correspondence  of 
the  Copious  Data  entity  to  the  line  entity  is  the  postprocessor's 
entity  mapping  for  the  IGES  Copious  Data  entity. 

The  entity  maps  can  be  used  as  a  first  step  in  predicting  the  expected 
completeness  of  data  exchange  between  two  systems.  Knowing  the  native 
entities  which  are  to  be  used  on  the  sending  (or  initiating)  system, 
the  end  user  can  follow  each  entity  through  the  entity  maps  for  both 
the  preprocessor  and  the  postprocessor  to  see  what  the  resulting 
entity  will  be  on  the  receiving  system. 
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4.3  Requirements  for  a  National  Verification  Program 

It  is  proposed  that  the  thrust  of  the  verification  of  a  processor 
be  the  substantiation  by  an  independent  agency  of  an  implementor's 
claims  for  tie  entity  mapping  and  other  processing  carried  out  by  a 
translator.  The  method  proposed  here  is  to  collect  this  information 
from  an  implementor  for  each  processor  to  be  verified,  and  then  to 
perform  sufficient  testing  so  as  to  verify  that  the  claims  made  are 
correct  and  that  the  entity  mapping  is  correctly  described. 

The  IGES  verification  program  will  be  sponsored  by  the  Society  of 
Automotive  Engineers  (SAE) .  It  is  one  of  several  verification 
programs  administered  by  them.  There  are  four  groups  which 
participate  in  the  verification  program;  the  SAE  staff,  the 
Technical  Board,  the  IGES  Verification  Panel,  and  the  testing 
agency ( s ) 

The  SAE  Technical  Board  serves  as  an  overseer  for  the  various 
review  panels  sponsored  by  the  SAE.  The  Board  reviews  and  approves 
the  operating  procedures  of  the  review  panels  as  well  as  their 
membership.  The  Technical  Board  is  also  responsible  for  ensuring 
that,  in  the  event  of  dispute,  the  appeals  procedure  as  outlined  in 
the  SAE  Technical  Board  Rules  and  Regulations  apply  and  are  carried 
out. 

The  IGES  Verification  Panel  will  come  under  the  jurisdiction  of 
and  report  directly  to  the  SAE  Technical  Board.  It  will  be 
composed  of  people  who  are  technically  competent  in  the  area  of 
IGES  and  CAD  data  exchange. 

Subject  to  approval  by  the  SAE  Technical  Board,  the  IGES 
Verification  Panel  will  formulate  operating  procedures,  rules  and 
operating  guidelines  ensure  that  the  verification  program 
adequately  serves  all  interested  parties,  including  industry  and 
the  general  public  while  adhering  to  the  principles,  policies,  and 
objectives  of  the  SAE. 

The  work  of  the  IGES  Verification  Panel  is  to  review  pertinent  test 
criteria,  testing  techniques  and  test  results  to  verify  that  IGES 
pre-  and  postprocessors  satisfy  the  requirements  of  data  exchange 
as  referenced  in  the  NBS  IGES  specification.  The  Panel  may  issue  a 
statement  to  the  interested  party  setting  forth  the  review  and 
determination  it  makes  to  verify  or  dispute  the  conclusion  reached 
by  the  testing  agency (s).  It  is  not  anticipated  that  the  scope 
of  the  Verification  Panel's  work  will  include  verification  of  all 
the  underlying  hardware  and  supporting  software  for  the  translators. 

The  IGES  Verification  Panel  will  consist  of  adequate  membership  to 
reflect  the  views  of  the  users,  interested  agencies,  laboratory 
testing,  and  other  interested  and  affected  parties.  Initially  the 
membership  will  be  appointed  by  the  SAE  Technical  Board. 

Subsequent  membership  will  also  be  approved  by  this  Technical  Board. 
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4.4  The  Verification  Process 


Initially  the  SAE  Testing  Program  is  directed  at  providing  a 
verification  that  a  vendor  claim  of  IGES  entity  processing  is 
correct.  This  has  the  effect  of  testing  on  an  entity  level  only  and 
leaves  a  user  to  verify,  first,  that  the  required  entities  are  present 
for  a  prescribed  application  subset  and,  second,  that  the  information 
is  being  mapped  correctly  into  and  out  of  those  entities.  In  later 
stages  of  the  SAE  Program,  subset  testing  may  be  possible. 

The  verification  process  is  initiated  by  an  implementor  completing 
a  Verification  Request  Package  and  submitting  it  to  the  with  the 
IGES  Verification  Panel  of  the  SAE.  The  verification  package 
contains  all  the  needed  information  including  the  implementors 
entity  maps  and  native  forms.  This  information  is  necessary  to 
enable  the  verification  testers  to  determine  which  test  cases  need 
to  be  executed. 

The  IGES  Verification  Panel  will  schedule  the  test  and  assign  a 
tester.  Using  the  information  on  the  request  form,  the  tester 
will  identify  the  test  cases  needed  from  the  test  library  and 
execute  a  test  plan  and  record  the  results.  These  results  will  be 
returned  to  the  IGES  Verification  Panel  for  a  decision  on  whether 
the  processing  of  the  translator  has  been  verified. 

The  IGES  Verification  Panel  will  notify  the  Presenter  of  its 
findings  prior  to  any  public  release  of  the  verification  material. 

The  Presenter  will  than  have  an  opportunity  to  respond  to  any 
problems  encountered  or  to  appeal  the  decision  of  the  Panel. 

When  a  translator  has  been  successfully  verified,  the  Verification 
Package  (the  request,  test  results,  and  summary  report)  will  be 
forwarded  to  a  sponsoring  government  agency  for  distribution.  This 
agency  will  distribute  copies  of  the  Summary  Report  and  the 
Verification  Package  on  retjuest. 


4.5  Current  Efforts  and  Status 

Prior  to  the  fall,  1986  IGES  meeting  in  Huntsville,  the  decision 
was  made  to  split  the  Testing  Methodology  Committee  into  six 
separate  committees.  This  action  was  deemed  necessary  because  of 
the  massive  effort  needed,  the  slow  progress  in  reaching  our  final 
goal,  and  the  difficulty  in  conducting  technical  meetings  with 
fifty  to  sixty  people  in  attendance.  The  functions  of  the  six 
committees  can  be  summarized  as  follows: 

-  Verification  Testing  Methodology  Committee  which  is 
responsible  for  establishing  verification  policy  and 
procedures  for  translator  testing.  This  is  the  general 
translator  testing  where  vendor  claims  are  verified 
against  test  libraries. 


-  Application  Validation  Methodology  Committee  which  is 
responsible  for  developing  the  concepts  of  application 
subset  testing  and  the  procedures  for  validating 
translators  for  specific  applications. 

-  Acceptance  Testing  Methodology  Committee  which  is  responsible 
for  developing  the  mechanisms  where  users  can  verify 

that  systems  will  work  correctly  in  their  user  environment. 

-  Methodology  Testing  Committee  which  is  responsible  for 
verifying  that  all  of  the  developed  procedures  are 
valid.  They  will  also  inspect  the  test  cases  and  audit 
the  IGES  verification  program. 

-  Test  Case  Development  Committee  which  is  responsible 
for  devising  the  guidelines  for  developing  and 
documenting  test  cases,  developing  the  test  cases,  and 
distributing  the  test  cases. 

-  User  Information  Committee  which  is  responsible  for 
developing  documentation,  gathering  and  distributing 
information,  and  developing  tutorials. 


Application  subset  testing  requires  a  known  testing  environment 
before  its  special  problems  can  be  addressed.  This  decision  may 
adversely  impact  MIL-STD-1840  development.  A  possible  interim 
method  will  be  discussed  in  a  following  section. 

The  Society  of  Automotive  Engineers  is  actively  pursuing  the 
initiation  of  an  IGES  Verification  Program  by  the  summer  of  1987. 
They  have  designated  members  for  the  Technical  Board  and  are  putting 
together  a  list  of  candidates  for  the  IGES  Verification  Panel. 
Universities  have  also  been  contacted  as  possible  sites  for  the 
translator  testing.  NBS  is  looking  for  a  way  to  provide  some  seed 
money  for  this  prograun.  The  major  problem  for  the  SAE  is  the  lack 
of  a  completely  defined  testing  program  with  ample  test  cases. 

NBS  is  sponsoring  two  meetings  in  February  1987  to  help  accelerate 
the  testing  program.  The  first  meeting  is  geared  to  developing  the 
criteria  for  test  cases,  test  case  documentation,  and  the 
generation  of  prototype  test  cases.  These  cases  will  be  used  the 
following  week  for  a  meeting  that  is  designed  to  revise  the  testing 
documentation  and  to  do  a  trial  run  of  the  verification  test  on  a 
CAD  system  at  NBS.  The  results  of  these  two  meetings  will  provide 
the  basis  for  the  testing  methodology  committee  agenda  at  the 
April  IGES  meeting. 

Through  the  User  Information  Committee,  NBS  has  been  contacting 
major  CAD  vendors  seeking  vendor  entity  maps,  permission  to  use  the 
maps  to  develop  IGES  testing  methods,  and  permission  to  release  the 
maps  to  the  public  as  part  of  the  reporting  and  education  process. 
The  vendor  response  has  been  very  positive  with  seven  vendors  having 
given  their  verbal  permission  to  use  their  mapping  data.  As  of  yet 
NBS  has  not  received  written  approval  from  these  vendors. 
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5 . 0  TECHNICAL  ISSUES 


The  restrictive  nature  of  the  application  siibset  concept  calls 
for  some  mechanism  to  limit  the  entity  content  of  the  IGES  file 
to  only  those  entities  specified  in  the  subset.  Further 
restrictions  exist  for  some  parameter  value  ranges  in  some 
specified  entities.  Enforcing  this  requirement  can  be  done  in 
several  ways: 

1.  Require  that  a  CAO  operator  generate  a  native  CAD  Model 
with  no  entities  that  will  be  mapped  to  IGES  entities 
outside  of  the  subset. 

2.  Configure  the  vendor  IGES  output  translator  to  enforce 
the  desired  subset  by  converting  native  entities  into 
conforming  IGES  entities. 

3 .  Develop  separate  software  routines  to  convert  an 
IGES  file  resulting  from  a  "best  try"  on  some  CAD 
system  into  a  conforming  subset  IGES  file. 


No  other  methods  are  known  for  assuring  that  the  needs  of  a 
prescribed  IGES  svibset  are  met.  Each  of  these  methods  places 
serious  restrictions  on  a  class  of  users,  and  these  drawbacks  are 
sure  to  cause  much  debate.  It  is  not  essential  that  one  method  be 
chosen  over  all  others.  Rather,  it  would  be  entirely  appropriate  to 
use  a  combination  of  the  three.  The  Pros  and  Cons  of  each 
alternative  are  explored  in  the  sections  to  follow. 


5.1  Control  Over  the  Operator  Selection  of  Entities 

A  CAD  system  offers  a  large  range  of  functionality  to  its  user 
community,  and  conventions  for  its  use  vary  from  shop  to  shop.  An 
operator  can  with  equal  ease  prepare  a  drawing  to  Y14.5 
specifications  or  intentionally  violate  accepted  drafting 
principles.  The  question  is  one  of  enforcing  a  policy,  and  the  CAD 
systems  of  today  generally  cannot  enforce  a  company  or  a  national 
policy  on  how  a  part  model  is  created. 

Similar  problems  exist  when  a  part  model  is  being  created  to  satisfy 
a  policy  on  application  subsets.  If  the  operator  makes  use  of  CAD 
menu  functions  which  create  entities  outside  of  the  prescribed 
subset,  the  IGES  file  created  by  a  general  purpose  translation 
process  will  be  noncompliant.  In  the  absence  of  any  other 
technique,  compliance  to  a  subset  absolutely  requires  that  an 
operator  not  be  allowed  to  use  certain  CAD  system  capabilities. 

This  requirement  can  only  be  relaxed  if  one  of  the  other  two 
methods  can  aid  in  the  conversion  of  entities  to  those  in  the 
subset. 


20 


5.2  Requirements  on  IGES  Translator  Design 

IGES  translator  designs  have  focused  on  faithfully  representing  the 
native  CAD  mo^el  in  the  IGES  entity  set  so  that  it  could  be  made 
available  to  a  "foreign”  process.  If  both  the  input  and  the  output 
translators  are  done  well,  an  IGES  file  generated  by  a  CAD  system 
can  be  read  back  into  the  same  system  to  create  a  part  model 
indistinguishable  from  the  first. 

As  our  attention  turns  to  generating  correct  application  subsets,  it 
should  be  understood  how  a  CAD  system  translator  could  be  of 
assistance.  An  IGES  output  translator  could  be  configured  to  do  any 
or  all  of  the  following: 

Flag  any  noncompliant  entities. 

Throw  away  any  native  entity  not  mapping  directly  to  a 
conforming  IGES  entity. 

Approximate  native  entities  with  the  closest  conforming  IGES 
entity. 

Approximate  native  entities  by  a  set  of  conforming  IGES  entities. 


While  these  would  be  valuable  functions  for  any  user  wishing  to 
prepare  an  IGES  file  conforming  to  an  application  subset,  they  place 
a  tremendous  burden  on  the  developer  of  IGES  translator  software. 
Consider  the  problem  of  developing  and  maintaining  separate  IGES 
translators  for  each  of  umteen  application  subsets. 


5 . 3  Flavoring  and  Deflavoring  Requirements 

Flavoring  is  a  term  that  is  used  to  describe  particular  practices 
built  into  a  translator  in  situations  where,  for  preprocessors,  the 
underlying  system  supports  entities  or  relationships  which  are  not 
directly  supported  by  IGES,  and,  for  postprocessors,  the  underlying 
system  does  not  handle  specific  entities  or  relationships  supported 
by  IGES.  Since  the  manner  in  which  these  situations  are  handled  is 
not  standardized,  other  knowledge  than  what  is  available  in  the  IGES 
document  is  needed.  This  additional  knowledge  is  frequently  built 
into  the  translators  and  results  in  files  that  have  a  noticable 
style  of  IGES  entity  construction. 

Flavoring  can  also  be  taken  to  mean  that  an  IGES  file  contains  legal 
IGES  entity  types  outside  the  range  of  a  particular  application 
subset,  i.e.  a  Linear  Dimension  entity  in  the  Tech  Pubs  subset.  One 
method  of  correcting  the  problem  is  to  write  a  flavor  converter 
which  reads  a  tainted  IGES  file  and  writes  a  correct  one.  In  the 
example  given,  the  offending  Linear  Dimension  is  approximated  in 
appearance  by  Line  entities  and  a  General  Note. 
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Construction  of  flavor  converters  is  not  trivial,  but  it  is  not  by 
any  means  an  enormous  project.  And  it  places  a  user  in  a  position 
of  control.  Standardized  input  and  output  routines  can  be  used  to 
ease  the  work*  Additional  functions  other  than  entity  manipulation 
can  be  performed  such  as  quality  control  over  all  datasets  shipped 
to  a  customer.  Certainly  it  is  a  valuable  tool  to  have  at  one's 
disposal  should  a  CAO  system  not  provide  all  the  functionality 
needed  for  a  particular  job. 


5.4  Software  Tools  for  Acceptance  Testing 

Since  the  DOD  will  soon  be  purchasing  and  accepting  IGES  files,  they 
will  need  a  software  package  that  can  verify  that  the  entities  in 
the  dataset  conform  to  both  the  application  subset  and  to  the  IGES 
specification.  This  can  either  be  accomplished  by  creating  new 
software  or  through  modification  of  one  of  the  commercial  IGES 
syntax  checkers. 

To  demonstrate  both  options,  the  CALS  Product  Data  Exchange  project 
at  NBS  has  developed  a  PC-based  program  and  has  made  changes  to  the 
IDA  Analyzer.  Using  a  test  file  library,  several  datasets  were 
tested  with  the  modified  IDA  analyzer  for  conformance  to  the 
technical  publishing  siabset.  The  analyzer  correctly  identified  the 
undefined  entities  and  ran  to  completion.  This  result  indicates 
that  separate  software  modules  do  not  have  to  be  used  to  check 
different  conformance  aspects  of  application  datasets.  The  IGES  QC 
analyzer  from  the  University  of  Leeds  has  not  been  used  to  test 
subset  conformance.  However,  representatives  from  the  University 
indicate  that  the  changes  to  do  so  would  be  simple. 

But  while  this  represents  a  good  start,  the  tools  require 
considerable  refinement  in  concert  with  the  evolving  application 
subsets.  In  the  future  a  better  array  of  tools  need  to  be  developed 
to  properly  test  the  processors  producing  the  datasets  and  the 
datasets  themselves.  The  software  needed  for  the  processor 
validation  will  be  expensive  to  develop.  Cost  estimates  to  date 
significantly  exceed  the  funds  available  to  the  IGES  office. 

Software  for  the  functionally  testing  will  take  longer  to  develop 
because  the  process  is  not  well  defined.  The  impact  of  the  lack  of 
these  software  tools  will  be  that  testing  will  be  less  rigorous  and 
be  much  more  labor  intensive. 
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5.5  Testing  of  Datasets  for  Conformance 

Because  IGES  entity  subsets  are  being  created  and  developed  to 
address  specific  ctpplication  areas,  the  concepts  of  dataset 
acceptance  issues  will  also  have  to  be  developed  in  parallel. 
Agencies  such  as  the  DOD  and  large  corporations  typically  build 
conformance  safeguards  into  their  contracts  so  that  they  know 
they  are  purchasing  correct  data  and  products.  IGES  in  its 
attempt  to  serve  as  broad  a  user  segment  as  possible  incurs 
special  conformance  problems  in  being  all  things  to  all  users. 

For  example,  not  only  is  geometry  being  communicated  but  also 
presentation  information,  associativity  information,  annotations, 
and  transformations. 

Acceptance  testing  represents  the  attempt  on  the  part  of  receiving 
agencies  to  guarantee  that  all  of  the  information  in  the  sending 
system  is  correctly  interpreted  in  the  target  system.  To  this  end, 
acceptance  can  be  broken  down  into  three  areas;  they  are 
functionality,  logical,  and  physical.  Functionality  is  the  highest 
level  and  the  most  difficult  to  test.  It  refers  to  the  semantics  or 
the  information  content  of  the  model  in  the  native  database  of  the 
sending  system.  Logical  testing  refers  to  the  entity  mapping  and 
system  limits  of  a  vendors  system  -  does  the  vendor  correctly  handle 
all  of  the  entities  in  the  subset  correctly  and  does  the  system 
generate  entities  not  included  in  the  subset.  Physical  checking 
refers  to  the  structure  of  the  data  file  and  its  syntax.  Files 
must  be  ccnstructed  properly  with  all  entities,  forms,  pointers  and 
associated  information  correctly  positioned.  Alphanumeric  rules' 
must  be  rigorously  followed,  data  type  conventions  followed,  units 
used  consistently,  and  precision  rules  followed.  This  type  of  test 
is  conceptually  simple  but  very  complex  because  of  the  allowable 
freedom  in  the  IGES  specification. 

Functional  checking  to  an  application  subset  specification  is  a 
complicated  process  that  is  currently  ill-defined  and  impossible 
to  test  exhaustively.  The  evaluation  system  for  such  functional 
testing  has  also  no  clear  consensus  at  this  time.  Such  subjects 
as  visual  equivalence,  pictorial  accuracy,  data  functionality, 
application  functionality  and  information  functionality  will  need 
further  discussion  and  evaluation. 

At  this  time  the  testing  method  for  IGES  transfer  of  any  kind  is 
the  visual  comparison  of  a  drawing  from  both  the  sending  and  the 
receiving  systems.  This  will  not  verify  that  the  functionality 
associated  with  entities  remain  intact.  For  example  collections 
of  lines  may  represent  a  cooling  system.  This  shortcoming  is 
serious  because  the  need  to  transfer  functionality  unambigiously 
is  the  primary  reason  for  the  existence  of  application  sxibsets. 

It  has  been  proposed  to  use  a  neutral  database  to  compare  IGES 
files  built  from  standard  reference  models  with  those  generated 
for  reference  scripts  on  a  vendors  CAD  system.  This  tool  would 
then  have  application  to  both  translator  verification  testing  and 
application  validation  testing.  Though  potentially  useful,  such 
a  verification  tool  is  expensive  and  not  currently  funded. 
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Actually  much  of  the  functionality  checking  is  for  application 
subsets  is  done  in  the  formulation  of  the  application  subset 
and  conventions  for  its  use. 

m 

Most  problems  with  IGES  files  are  rooted  in  the  inherent 
ambiguities  of  the  specification  and  imprecise  vendor 
translations  of  IGES  entities.  With  subsets,  constraints  on 
allowable  constructs  reduce  semantic  difficulties  reducing  the 
potential  for  error.  There  is  no  longer  redundant  constructs  and 
as  a  consequence  the  translators  will  be  smaller  and  easier  to 
maintain. 

Physical  conformance  testing  is  an  exhaustive  process  where  IGES 
files  are  checked  for  strict  adherence  to  the  IGES  specification. 
Such  programs  are  large,  tedious,  and  absolutely  essential.  These 
syntax  checkers  must  check  all  of  the  entities,  their  forms, 
attributes,  associations,  structures,  construction  details  and 
organization.  Fortunately,  there  are  two  commercial  products  that 
can  do  these  tests.  They  are  the  'IGES  Analyzer'  from  IGES  Data 
Analysis  Corporation  and  'IGES  QC'  from  the  University  of  Leeds 
in  the  UK.  Both  checkers  are  available  at  a  reasonable 
cost  to  run  on  Vax  based  systems.  The  IDA  analyzer  also  runs  on 
UNIX  based  systems.  Both  systems  have  been  exercised  with  sample 
IGES  test  files  and  found  to  be  satisfactory.  These  checkers  have 
the  additional  benefit  that  they  can  check  sxibset  conformance 
with  their  syntax  check. 

Conformance  of  entities  to  the  application  subset  is  the  easiest 
test.  A  conformance  checker  must  be  able  to  read  an  IGES  file  and 
and  extract  the  data  from  it.  Next  the  program  must  inspect  the 
entities  in  the  file  and  verify  that  they  are  members  of  a  target 
subset.  Such  a  conformance  program  has  been  written  at  NBS  in  the 
Basic  language.  This  program  is  in  the  public  domain  and  when 
documentation  is  complete  can  be  copied  freely.  The  program  is 
expected  to  be  the  first  building  block  in  what  will  be  a  series 
of  IGES  utility  programs.  It  is  impoirtant  to  bear  in  mind  that, 
although  checking  subset  conformance  to  the  subset  specification 
is  necessary,  it  is  by  no  means  a  sufficient  test.  IGES  files  are 
more  likely  to  be  in  error  syntactically  or  functionally. 
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Table  2  Sum*ary  of  Testing  Levels 


TYPE  OF 

TEST 

Phys ical 

Logical 

Functional 

WHAT  IS 

TESTED 

Syntax  and 
Structure 

Entity  Mapping 
and 

System  Limits 

End-to-End 

Data  Exchange 

BASIS  FOR 

TEST  DATA 

IGES 

Specif ication 

IGES 

Specification 

and 

Implementor ' s 
_Entity  Map  __  _ 

Appl ication 
Requirements  and 
Implementor '  s 
Entity  Map 

TESTER 

Implementor 

Verifying 

Agency 

End  User 

TEST 

METHOD 


Preprocessors 

Modeling  script-to-IGES  File 


Postprocessors 
ICES  f ile-to-databsse 


evaluation 


Error  Log 


Preprocessors 


IGES  model 
conparisons 


Postprocessors 


Syntax 

Checker 


CAD  model 

comparisons 

Operational 

tests 

Geometric 

veri f icat ion 


PURPOSE  OF 
TEST  AND 
USE  OF 
RESULTS 


Error 

Detection 


Formal 

Ver i f ication 


Before  and  after 
comparison  with 
respect  to  uses* 
criteria 

-  Visual  comparison 

-  Operational  and 
functional  tests 

-  Database  content 


Applicability  in 
specific  applica¬ 
tion  <»nvironmenr 


6 . 0  POLICY  CONSIDERATIONS 


6.1  Policy  on  Purchase  of  Datasets 

DOD's  stated  intent  is  to  begin  use  of  digital  product  data  files  by 
1990.  A  draft  Policy  Instruction  for  product  data  is  given  in 
Appendix  A.  This  refers  to  a  draft  MIL-STD  on  Product  data  given 
in  Appendix  B  and  to  a  series  of  IGES  application  subsets  given 
by  a  draft  MIL-SPEC  in  Appendix  C. 

Service  elements  have  already  started  prototype  exchange  as  early  as 
1985,  and  a  1984  NAVSEA  Policy  Instruction  states  that  IGES  is  to  be 
invoked  on  all  new  contracts  involving  transfer  of  CAD/ CAM  data. 

But  in  dealing  with  dataset  transfers  in  a  contract  situation,  the 
problem  is  compounded  with  questions  of  data  rights,  liability  and 
dual  authority. 

While  there  may  be  many  issues  raised  as  to  data  rights,  it  is 
believed  that  the  use  of  digital  transfers  introduces  no  change 
over  the  traditional  use  of  engineering  drawings.  But  invariably 
contractors  will  be  more  reluctant  to  part  with  their  CAD  databases. 

The  liability  issue  is  scan  not  in  the  purchase  of  datasets  as  much 
as  when  the  governmer.c  .'urnishes  the  datasets  to  a  contractor  as 
part  of  a  contractual  relationship.  If  the  data  exchange  is 
perfect,  it  seems  there  is  no  more  of  a  liability  problem  than  .when 
a  drawing  is  furnished.^.  However,  the  question  of  liability  for 
wrongful  or  incomplete  information  as  a  result  of  less  than  perfect 
software  translators  is  difficult  to  prejudge. 

Intriguing  questions  abound  on  the  issue  of  dual  authority  - 
drawing  or  dataset.  The  formal  engineering  drawing  of  today  is 
still  the  authority  for  product  definition.  Steeped  in 
tradition,  codified  by  ANSI  standard,  tested  in  the  courts  and 
cited  by  MIL-SPEC  and  MIL-STD,  the  drawing  will  remain  a  useful 
tool  so  long  as  man  wishes  to  interpret  the  geometry,  topology, 
tolerances  and  features  of  a  product  design.  Yet  few  will  argue 
that  someday  we  will  place  far  more  imortance  on  the  exchange  of 
digital  product  descriptions  than  we  do  paper.  Drawings  will 
become  a  by-product  derived  from  the  received  dataset  for  the 
purpose  of  aiding  human  understanding  of  the  dataset.  The  drawing 
will  not  be  a  primary  method  for  information  exchange.  However,  no 
one  is  able  to  cite  exactly  when  this  will  happen. 

The  term  "dual  authority"  alludes  to  the  interim  period  of  time 
when  datasets  and  drawings  are  both  in  typical  use  in  data 
exchanges.  Which  should  take  precedence  if  an  Inconsistency  is 
found?  Experience  is  that  this  happens  often  enough  to  require 
serious  consideration.  One  instance  was  reported  in  which 
digital  information  in  IGES  format  was  in  typical  use.  A  last 
-minute  change  to  a  critical  dimension  was  made  to  the  text  note 
of  a  linear  dimension  in  the  CAD  system  rather  than  by  modifying 
the  part  geometry  being  dimensioned.  Since  the  part  was  made 
from  the  received  geometry  rather  than  from  a  model  created  from 
the  received  CAD  generated  drawing,  the  part  was  wrong. 
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6.2  Acceptance  Testing  of  Datasets 


Acceptance  testing  of  datasets  by  the  government  must  be  complete 
enough  to  ascertain  that  the  datasets  are  of  sufficient  quality  to 
meet  the  contract  specifications  for  payment.  Acceptance  testing 
represents  the  attempt  on  the  part  of  receiving  agencies  to 
guarantee  that  all  of  the  information  in  the  sending  system  can  be 
correctly  interpreted  by  the  target  system. 

At  this  time  the  typical  testing  method  for  IGES  transfer  is 
the  visual  comparison  of  a  drawing  from  both  the  sending  and  the 
receiving  system.  This  will  not  verify  that  the  functionality 
associated  with  entities  remains  intact.  The  limitation  is  serious 
because  the  need  to  transfer  functionality  unambigiously  is  the 
primary  reason  for  the  existence  of  application  subsets. 
Fortunately,  software  tools  are  beginning  to  be  developed  to  meet 
this  challenge.  These  are  already  in  the  prototype  stage. 

Priority  should  be  given  to  supporting  their  creation. 


6.3  Verification  of  Source  Preparation  Systems 

Procedures  are  needed  by  those  who  will  be  producing  IGES 
application  subset  files  as  contract  deliverables  to  verify  the 
ability  of  their  systems  to  conform.  A  first  step  is  to  require 
SAE  application  subset  validation  as  a  part  of  each  new  system 
purchase.  But  this  does  not  address  all  those  systems  in  the 
installed  base.  Certainly  the  same  procedures  used  by  SAE  could 
be  followed,  but  the  skilled  personnel  resources  may  not  be 
available  to  the  smaller  firms. 
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7.0  ACTION  REQUIRED  TO  IMPLEMENT 

A  formal  strategy  is  needed  to  effectively  implement  digital 
exchange  of  technical  data  within  the  DOO.  A  draft  policy 
instruction  on  the  subject  is  given  in  Appendix  A. 

Technical  data  can  be  divided  into  unstructured  text,  technical 
dociimentation  and  product  data.  Unstructured  text  is  outside  the 
scope  of  this  report.  The  exchange  of  technical  documentation  in 
digital  form  is  addressed  by  MIL-STD  1840  which  already  exists 
and  is  in  final  stages  of  coordination.  Product  data  exchange  is 
the  subject  of  this  report.  It  is  thought  that  this  can  best  be 
addressed  by  creating  a  DOD-wide  MIL-STD  similar  to  1840  but  which 
addresses  the  entire  range  of  digital  product  data  applications, 
not  just  technical  documentation.  This  is  given  in  draft  form  in 
Appendix  B.  This  document  represents  a  major  rewrite  of  1840. 

To  fill  the  need  for  a  complete  and  precise  specification  on  IGES 
application  subsets,  a  new  Military  Specification  is  proposed. 

This  is  given  in  draft  form  in  Appendix  C.  It  contains  siibsets 
for  technical  illustrations,  2-D  engineering  drawings  and 
electronic  printed  wiring  boards.  These  three  subsets  are  only 
the  start  of  several  which  will  form  the  completed  MIL-SPEC. 

A  number  of  actions  are  necessary  to  provide  implementation  of 
this  strategy  for  application  subsets  throughout  the  DOD.  A  list 
is  given  here  for  consideration  by  the  CALS  Office: 

The  draft  DOD  Policy  Instruction  for  Digital  Product  Data 
Exchange  given  in  Appendix  A  should  be  reviewed  by  the  CALS 
Office  and  circulated  for  adoption  by  all  commands. 

The  draft  Military  Standard  for  Digital  Product  Data 
Exchange  given  in  Appendix  B  should  be  reviewed  by  the  CALS 
Office  and  circulated  for  adoption.  This  MIL-STD  references 
the  MIL-SPEC  on  IGES  application  subsets  in  Appendix  C. 

The  draft  Military  Specification  on  IGES  Application  Subsets 
given  in  Appendix  C  should  be  reviewed  by  the  CALS  Office 
and  circulated  for  adoption. 

The  DOD  community  should  be  polled  for  additional 
engineering  disiplines  requiring  IGES  application  subsets 
including  a  request  for  priority  ranking  of  needs.  This  can 
best  be  done  through  the  NSIA  CALS  committees,  the  DOD 
Manufacturing  Technology  Advisory  Group,  inhouse  program 
managers  from  all  service  components  concerned  with  each 
application,  CALS  service  contacts  and  members  of  the  IGES 
Organization  who  are  in  the  DOD  or  affected  companies. 
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REFERENCES 


Glossary 

Acceptance  Testing  -  The  testing  performed  by  a  user  to 
determine  the  suitability  of  a  translator  for  a  specific 
environment. 

Application  Validation  -  The  testing  which  is  aimed  at 
ensuring  that  application  subsets  of  IGES  are  treated  in  a 
manner  consistent  with  the  application  on  the  system  under 
test.  See  also  Conformance  Testing. 

CAD  Model  -  The  representation  of  a  product  definition 
model  in  a  CAD  system^s  native  form.  See  also  IGES  Model. 

Certify  -  To  guarantee  the  quality  or  worth  of;  to  vouch 
for.  Webster ^s  New  World  Dictionary-1972U 

Conformance  Testing  -  The  testing  which  is  aimed  at 
ensuring  that  the  processing  of  individual  entities  and 
data  items  accurately  reflects  IGES  specification. 

Entity  -  The  basic  unit  of  information  in  an  IGES  file.  This 
term  applies  to  single  items  which  may  be  individual  elements  of 
geometry,  collections  of  annotation  to  form  dimensions,  or 
collections  of  entities  to  form  structured  entities. 

Entity  Mapping  -  The  change  of  entity  definition  during 
conversion  between  data  formats.  This  conversion  may  result 
in  a  change  of  mathematical  definition  but  maintains  the  same 
information  content. 

Evaluation  Criteria  -  The  set  of  items  in  the  test  results 
which  are  to  be  examined,  along  with  the  means  of 
measuring  how  these  items  indicate  the  performance  of  the 
processor  under  test.  These  criteria  will  typically  be 
defined  on  a  test-by-test  basis  and  will  describe  the 
features  of  the  test  that  are  of  interest.  For  example, 
the  Evaluation  Criteria  for  a  line  might  be  its  position 
in  the  model  and  its  length.  Here,  a  comparison  of  the 
expected  position  with  the  resulting  position  would  be 
defined  for  the  test.  See  also  Validation  Criteria. 

Functionality  -  The  ability  to  edit,  move,  scale  or  otherwise 
manipulate  a  postprocessed  entity  as  if  it  were  created 
originally  on  the  receiving  system. 

IGES  Model  -  The  representation  of  a  product  definition 
model  in  IGES  format.  This  is  usually  in  the  form  of  an 
IGES  file.  See  also  CAD  Model. 

Standard  Reference  Model  -  The  representation  of  a  product 
definition  model  prior  to  being  processed  by  an  IGES 
translator.  See  also  Test  Results  Model. 


Test  Data  Library  -  The  collection  of  data  sets,  along 
with  the  docximentation  for  the  data  sets,  which  are  to  be 
used  in  the  testing  of  processors.  Data  sets  in  the  Test 
Library  exercise  specific  features  of  the  standard  and 
include  both  correct  and  incorrect  data.  A  given  data  set 
may  take  part  in  more  than  one  Test  Script. 

Test  Methodology  -  A  high  level  definition  of  testing 
philosophy,  practices,  issues  and  general  procedures.  It 
contains  the  rationale  of  test  procedures,  the  kind  of 
testing  that  is  necessary,  and,  in  general  terms,  how  to 
conduct  tests. 

Test  Procedures  -  Descriptions  of  the  various  tests  that 
are  necessary  to  test  a  particular  aspect  of 
implementations  of  the  standard.  These  procedures 
identify  the  test  data  and  the  processes  that  are  to  be 
used  in  testing.  This  will  generally  contain  reference  to 
a  set  of  specific  Test  Scripts. 

Test  Result  Model  -  The  representation  of  a  product 
definition  model  after  being  processed  by  an  IGES 
translator.  See  also  Standard  Reference  Model. 

Test  Scripts  -  The  detailed,  step-by-step  instructions 
which  describe  how  to  conduct  a  test.  Scripts  will 
contain  references  to  specific  data  sets  in  the  Test 
Library  which  are  to  be  used.  A  log  for  docxamenting  each 
test  should  also  be  provided.  Discussion  of  specific 
Evaluation  Criteria  will  also  be  included. 

Validation  Criteria  -  The  specifications  that  a  test 
analyst  will  use  to  determine  the  applicability  of  a  piece 
of  software  for  a  specific  application.  These  are  based 
on  the  results  of  applying  the  Evaluation  Criteria  (q.v.) 
and  usually  identify  a  minimum  acceptable  level  of 
performance.  For  example,  if  the  Evaluation  Criterion  for 
a  line  is  its  position,  then  the  Validation  Criterion  for 
the  test  might  be  that  the  position  may  not  vary  by  more 
than  .001  inches,  or  perhaps  by  more  than  1%  of  the 
coordinate  value. 

Verify  -  To  test  or  check  the  accuracy  or  correctness  of, 
as  by  investigation,  comparison  with  a  standard  or 
reference  to  the  facts.  Webster's  New  World 
Dictionary-1972U. 

Verification  Criteria  -  The  specific  criteria  that  a 
verifying  body  will  use  to  assign  functionality  ratings  to 
a  processor.  These  criteria  will  be  defined  by  the 
Testing  Methodology  Committee. 
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DRAFT  POLICY  INSTRUCTION  FOR  DOD  ADOPTION 


APPENDIX  A 


SCOPE: 

This  instruction  addresses  the  specification,  purchase  and 
acceptance  testing  of  product  data  in  digital  form  throughout  the 
DoD.  It  promulgates  mechanisms  for  incorporating  the  exchange  of 
digital  product  data  into  the  normal  procurement  and  business 
operations  of  the  DOD.  Requirements  are  given  for  the 
specification,  purchase  and  acceptance  testing  of  product  data  in 
digital  form.  Use  of  application  subsets  of  the  Initial  Graphics 
Exchange  Specification  (IGES)  Version  4.0,  1987  is  directed  by 
citations  to  appropriate  MIL-STD's  and  MIL-SPEC' s. 


OBJECTIVE: 

The  objective  of  the  Computer  Aided  Logistics  program  in  digital 
product  data  is  the  effective  exchange  of  data  throughout  the 
life  cycle  of  weapons  systems  development  and  deployment  through 
the  use  of  computer- readable  datasets  describing  the  systems, 
their  individual  piece  parts  and  their  product  support  data.  A 
central  issue  here  is  the  technology  of  digital  representation  of 
product  data  in  its  many  forms  of  illustrations,  drawings,  3-D 
wire  frame  models,  surfaced  models,  solids  models  and  complete 
product  models. 


BACKGROUND: 

The  CALS  Program  in  product  data  exchange  addresses  the  exchange, 
archiving  and  future  use  by  DOD  of  digital  product  data.  Major 
thrusts  are: 

Development  of  a  comprehensive  program  of  testing  and 
evaluation 

Identification  and  solution  of  problems  encountered  in 
intersystem  data  exchange 

Research  into  the  unique  requirements  for  long  term 
archiving 

Development  of  software  tools  to  assist  users  in  making 
routine  production  use  of  digital  product  data 

Continued  development  of  new  applications  capability 

Validation  of  new  applications  areas 

Developmental  work  on  methods  for  complete  product  model 
data  representation 
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Throughout  the  DOD  and  its  partners  in  industry,  an  increasingly 
larger  number  of  computer  aided  design  systems  are  being  used  in 
all  phases  of  design,  analysis,  manufacture  and  test  of  weapons 
products^  Over  a  hundred  vendors  offer  these  CAD  systems.  And 
it  is  natural  that  different  DOD  activities  or  different 
companies  would  choose  different  vendor  systems  to  meet  their 
varying  needs.  Hence,  there  is  a  requirement  in  the  normal 
course  of  business  to  be  able  to  exchange  the  digital  part  models 
that  are  developed  on  one  system  to  be  used  on  another  system. 

It  is  essential  for  CALS  to  be  able  to  fully  utilize  these 
automation  resources  both  at  contractor  and  subcontractor 
facilities  as  well  as  inhouse  for  design  review,  second  sourcing, 
overhaul  planning  and  spare  part  production.  Digital  product 
data  exchange  plays  a  key  role  in  each  of  these  areas. 


DIGITAL  PRODUCT  DATA: 

Two  terms  will  be  used;  product  definition  data  and  product  data. 
Product  Definition  Data  denotes  the  totality  of  data  elements  to 
completely  define  the  product.  Product  definition  data 
includes  the  geometry,  topology,  relationships,  tolerances, 
attributes  and  features  necessary  to  completely  define  a 
component  part  or  an  assembly  of  parts  for  the  purposes  of 
design,  analysis,  manufacture,  test,  inspection.  Ve^  little,  if 
any,  process  data  is  included,  with  the  exception  being  reference 
to  a  process  standard  or  reference  to  a  procedure  which  results 
in  a  product  condition  that  is  not  easily  specified,  e.g.,  heat 
treating  for  1  hour  at  320  degrees.  The  product  definition  is 
expected  to  be  sufficiently  complete  to  enable  the  generation 
of  all  downstream  process  data. 

Product  Data  is  more  broadly  defined  than  Product  Definition 
Data.  Product  data  includes  all  of  the  product  definition  data 
plus  a  larger  class  of  data  elements  necessary  to  fully  support 
the  product  for  all  applications  over  its  expected  life  cycle. 


LIFE  CYCLE  USE: 

Indicative  of  this  larger  class  of  product  data  are  engineering 
analysis  models  or  results  and  illustrations  of  the  product  to  be 
used  in  documentation  regarding  operation,  maintenance  and 
engineering  change  control.  Product  data  spans  the  entire  range 
of  disiplines  from  conceptual  design  and  engineering  analysis  to 
manufacturing  planning,  production,  test,  inspection  and 
deployment.  Data  packages  are  expected  to  go  through  repeated 
exchanges  between  primes,  subs,  government  project  managers,  test 
labs  and  consultants. 
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EXTENT  OF  USE: 


The  CALS  Program  requires  the  ability  to  deal  with  digital 
product  data  for  four  generic  applications: 

Internal  transfer  of  product  data  among  DOD  components 

The  acquisition  of  new  manufactured  parts/systems 

Data  transfer  fom  Design  systems  to  Product  Support  systems 

Archival  storage  of  parts/assembly  information 

Numerous  internal  transfers  of  product  models  are  found  in  R&O, 
prototype  design,  overhaul  and  retrofit  planning,  and  each  is  a 
candidate  for  digital  exchange  in  the  immediate  future. 


ECONOMIC  BENEFITS: 

Digital  product  data  is  becoming  an  important  consideration  in 
DOD's  contractual  relationship  for  purchase  of  manufactured 
parts,  assemblies  or  whole  systems. 

DOD  has  significant  investments  in  data  archives  necessary  to 
support  its  deployed  forces.  Presently  this  data  consists  of 
millions  of  drawings  stored  in  data  repositories,  but  many 
agencies  are  beginning  to  address  the  problem  of  long-term 
archiving  of  digital  product  data. 

The  economic  significance  of  digital  product  data  is  easily  seen 
from  these  examples.  Efficiency,  accuracy  and  leadtime 
improvements  are  all  substantially  enhanced  through  the  use  of 
CAD  and  CAM  technology  made  possible  by  the  sharing  of  product 
data. 


APPLICATION  SUBSETS: 

Each  application  of  CAD/CAM  has  different  requirements  for 
the  data  describe  the  product  model.  The  Initial  Graphics 
Exchange  Specification  provides  a  mechanism  for  representing 
product  data  in  a  neutral  public  domain  format.  Subsets  of  IGES 
entities  will  be  used  as  required  to  support  the  information 
exchange  needs  of  different  design,  engineering,  manufacturing 
and  product  support  areas. 

An  application  subset  of  IGES  is  defined  as  a  set  of  specific 
IGES  entity  types  which  are  used  to  completely  and  unambiguously 
represent  the  information  requirements  of  the  product  for  the 
named  application  purpose. 
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APPLICABLE  MILITARY  STANDARDS: 

MIL-STD  1840  defines  the  digital  representation  of  technical 
documentation  with  associated  drawings.  MIL-STD  184x  addresses 
the  exchange  of  digital  product  data.  Both  MIL-STD 's  make 
reference  to  IGES  application  subsets  given  in  MIL-SPEC  nnnn. 

POLICY: 

Application  Subsets  of  IGES  Version  4.0  as  expressed  by 
implementing  Military  Specifications  and  Standards  shall  be  used 
for  exchanging  product  data. 


ACTION: 

MIL-STD  Application  Subsets  will  be  invoked  on  all  contracts 
calling  for  exchange  of  digital  product  data. 

All  offices,  activities  and  detachments  shall  ensure  that  all 
sollicitations,  proposals  and  contracts  for  new  construction, 
conversion,  modification,  modernization  and  overhaul  require 
aelivery  of  any  generated  digital  product  data  in  the  appropriate 
MIL-STD  format. 

Renegotiation  of  existing  contractural  agreements  is  encouraged 
where  cost  effective  and  feasible. 

All  DOD  repositories  of  technical  information  on  product 
definition  including  engineering  drawings  shall  formulate  plans 
and  implement  mechanisms  for  accepting,  archiving  and  furnishing 
as  necessary  digital  product  datasets  in  MIL-STD  format. 

Where  digital  product  data  along  with  appropriate  engineering 
drawings  is  made  available  to  a  contractor  by  a  DOD  componenr  as 
government  furnished  equipment,  it  shall  be  marked  for  reference 
purposes  only  with  the  drawing  made  prime  authority. 

In  those  situations  where  spare  parts  are  purchased  from  an 
inhouse  facility  or  from  a  contract  source,  extra  incentives 
should  be  offered  to  develop  and  capture  the  digital  product  data 
in  MIL-STD  format  for  future  logistics  use. 


EXCEPTIONS : 

In  situations  where  both  sender  and  receiver  possess  the  same 
hardware  and  software,  native  CAD  system  database  files  should  be 
requested  in  addition  to  the  IGES  MIL-STD  Application  Subsets, 

The  native  data  will  satisfy  the  present  need  while  the  IGES  will 
serve  longer  range  or  unforeseen  future  needs. 
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DRAFT  MILITARY  STANDARD  FOR  DOD  ADOPTION 


APPENDIX  B 


NOTE:  This  draft,  dated  23  February  87  prepared  by  Div  732 

National  Bureau  of  Standards,  has  not  been  approved  and  is 
subject  to  modification.  DO  NOT  USE  FOR  ACQUISITION  PURPOSES. 
Project  NBS  CALS  Product  Data. 


MILITARY  STANDARD 
EXCHANGE  OF  DIGITAL  PRODUCT  DATA 


Beneficial  comments  (  recommendations,  additions  deletions) 
and  any  pertinent  data  which  may  be  of  use  in  improving  this 
document  should  be  addressed  to  Bradford  Smith,  Bldg.  220, 

Rm  A353,  Bureau  of  Standards,  Gaithersburg,  MD  20899  by 
using  the  self-addressed  Standardization  Document 
Improvement  Proposal  (DD  Form  1426)  appearing  at  the  end 
of  this  document  or  by  letter. 


DISTRIBUTION  STATEMENT  A.  Approved  for  public  release; 

distribution  is  unlimited. 
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MIL-STD-184X 


FOREWORD 


The  CALS  Program  in  product  data  exchange  addresses  the  exchange, 
archiving  and  future  use  by  DOD  of  digital  product  data.  Major 
thrusts  are: 

Development  of  a  comprehensive  program  of  testing  and 
evaluation 

Identification  and  solution  of  problems  encountered  in 
intersystem  data  exchange 

Research  into  the  unique  requirements  for  long  term 
archiving 

Development  of  software  tools  to  assist  users  in  making 
routine  production  use  of  digital  produce  data 

Continued  development  of  new  applications  capability 

Validation  of  new  applications  areas 

Developmental  work  on  methods  for  complete  product  model 
data  representation 

Throughout  the  DOD  and  its  partners  in  industry,  an  increasingly 
larger  nximber  of  computer  aided  design  systems  are  being  used  in 
all  phases  of  design,  analysis,  manufacture  and  test  of  weapons 
products.  Over  a  hundred  vendors  offer  these  CAD  systems.  And 
it  is  natural  that  different  DOD  activities  or  different 
companies  would  choose  different  vendor  systems  to  meet  their 
varying  needs.  Hence,  there  is  a  requirement  in  the  normal 
course  of  business  to  be  able  to  exchange  the  digital  part  models 
that  are  developed  on  one  system  to  be  used  on  another  system. 

It  is  essential  for  CALS  to  be  able  to  fully  utilize  these 
automation  resources  both  at  contractor  and  subcontractor 
facilities  as  well  as  inhouse  for  design  review,  second  sourcing, 
overhaul  planning  and  spare  part  production.  Digital  product 
data  exchange  plays  a  key  role  in  each  of  these  areas. 
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MIL-STD-184X 


1 .  SCOPE 


1.1  Scope.  This  standard  addresses  the  specification,  purchase 
and  acceptance  testing  of  product  data  in  digital  form  throughout 
the  DOD.  It  promulgates  mechanisms  which  shall  be  used  when 
digital  product  data  is  to  be  exchanged  in  normal  procurement  and 
business  operations. 


1.2  Purpose.  The  purpose  of  this  standard  is  to  specify  the 
representation  of  digital  product  data  to  facilitate  the  effective 
exchange  of  this  information  throughout  the  life  cycle  of  weapons 
systems  development  and  deployment.  This  is  accomplished  through 
the  exchange  of  computer  readable  datasets  describing  the  systems, 
their  individual  piece  parts  and  their  product  support  data.  A 
central  issue  here  is  the  technology  of  digital  representation  of 
product  data  in  its  many  forms  of  illustrations,  drawings,  3-D  wire 
frame  models,  surfaced  models,  solids  models  and  complete  product 
models. 
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MIL-STD-184X 

2 .  APPLICABLE  DOCUMENTS 


2 . 1  Government  documents . 

2.1.1  Specifications,  standards,  and  handbooks.  The 
following  specifications,  standards,  and  handbooks  form  a  part 
of  this  specification  to  the  extent  specified  herein.  Unless 
otherwise  specified,  the  issues  of  these  documents  shall  be 
those  listed  in  the  issue  of  the  Department  of  Defense  Index  of 
Specifications  and  Standards  (DODISS)  and  supplement  thereto, 
cited  in  the  solicitation. 

a.  MIL-STD-100  Engineering  Drawing  Practices 

b.  MIL-STD-D-1000  Engineering  Drawings  and  Associated  Lists 

c.  MIL-STD-804B  Formats  and  Coding  of  Aperature  Cards 


2.1.2  Other  Government  documents,  drawings,  and  publications. 

The  following  other  government  documents,  drawings,  and  publications 
form  a  part  of  this  specification  to  the  extent  specified  herein. 
Unless  otherwise  specified,  the  issues  of  these  documents  shall  be 
those  in  effect  on  the  date  of  the  solicitation. 


2.2  Other  Publications.  The  following  documents  form  a  part  of 
this  standard  to  the  extent  specified  herein.  Unless  otherwise 
indicated,  the  issue  in  effect  on  the  date  of  invitation  for  bids  or 
request  for  proposal  shall  apply,  or  as  otherwise  specified  in  the 
contract. 

a.  Initial  Graphics  Exchange  Specification,  Version  3.0,  NBSIR 
86-3359,  April  1986,  U.S.  Department  of  Commerce,  National 
Bureau  of  Standards. 

(Application  for  documents  should  be  addressed  to  National 
Technical  Information  Service,  5285  Port  Royal  Road, 
Springfield,  VA  22161,  Document  Number  86-199-759) 


2.3  Order  of  precedence.  In  the  event  of  a  conflict  between  the 
text  of  this  standard  and  the  references  cited  herein,  the  text  of 
this  standard  shall  take  precedence. 
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3 .  DEFINITIONS 

3.1  Acronyms  used  in  this  text.  The  acronyms  used  in  this  text 
are  defined  as  follows: 

a.  IGES  -  Initial  Graphics  Exchange  Specification 

b.  ASCII  -  American  Standard  Code  for  Information  Interchange 

c.  EDIF  -  Electronic  Design  Interchange  Format 

d.  VHSIC  ~  Very  High  Speed  Integrated  Circuit 


3.2  Application  Subset.  An  application  subset  of  IGES  is 
defined  as  a  set  of  specific  IGES  entity  types  which  are  used  to 
completely  and  un2UDbiguously  represent  the  information 
requirements  of  the  product  for  the  named  application  purpose. 


3.3  Initial  Graphics  Exchange  Specification.  IGES  provides  a 
mechanism  for  representing  digital  product  data  in  a  neutral 
public  domain  format.  Information  is  represented  as  geometry, 
annotation  and  structural  relationships  among  the  entities. 


3.4  Product  Data.  Includes  all  of  the  product  definition  data 
plus  a  larger  class  of  data  elements  necessary  to  fully  support 
the  product  for  all  applications  over  its  expected  life  cycle. 


3.5  Product  Definition  Data.  The  totality  of  data  elements  in 
a  digital  dataset  necessary  to  completely  define  the  product. 
Product  definition  data  includes  the  geometry,  topology, 
relationships,  tolerances,  attributes  and  features  necessary  to 
completely  define  a  component  part  or  an  assembly  of  parts  for  the 
purposes  of  design,  analysis,  manufacture,  test,  inspection.  Very 
little  if  any  process  data  is  included,  with  the  exception  being 
reference  to  a  process  standard  or  reference  to  a  procedure  which 
results  in  a  product  condition  that  is  not  easily  specified. 
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4.  GENERAL  REQUIREMENTS 


4 . 1  General .  Throughout  the  DOD  and  its  partners  in  industry , 
an  increasingly  larger  nuotber  of  computer  aided  design  systems  are 
being  used  in  all  phases  of  design,  analysis,  manufacture  and  test 
of  weapons  products.  Over  a  hundred  vendors  offer  these  CAD 
systems.  And  it  is  natural  that  different  DOO  activities  or 
different  companies  would  choose  different  vendor  systems  to  meet 
their  varying  needs.  Hence,  there  is  a  requirement  in  the  normal 
course  of  business  to  be  able  to  exchange  the  digital  part  models 
that  are  developed  on  one  system  to  be  used  on  another  system. 

4.2  Digital  Product  Data.  Product  Data  includes  the  totality 
of  data  elements  in  a  digital  dataset  necessary  to  completely 
define  a  piece  part,  an  assembly  of  parts  or  an  entire  weapons 
system.  The  term  includes  the  geometry,  topology,  relationships, 
tolerances,  attributes  and  features  necessary  to  completely  define 
the  product  and  support  its  lifetime  use. 

4.2.1  Extent  of  Use.  Product  data  spans  the  entire  range  of 
disiplines  from  conceptual  design  and  engineering  analysis  to 
manufacturing  planning,  production,  test,  inspection  and 
deployment.  Data  packages  are  expected  to  go  through  repeated 
exchanges  between  primes,  subs,  government  project  managers  and 
test  labs. 

4.3  Digital  Data  Exchange.  Product  data  can  be  exchanged  by 
way  of  the  neutral  data  formats.  IGES  is  in  widespread  use  for 
Mechanical  part  models  and  has  extensions  to  technical 
illustrations,  electrical  printed  wiring  boards,  architectural 
engineering,  manufacturing  and  finite  element  analysis.  EDIF  and 
VHSIC  are  being  developed  for  integrated  circuit  product  designs. 

4.4  IGES  Data  Exchange.  In  a  data  exchange  with  IGES, 
information  is  carried  as  a  series  of  entities  describing 
geometry,  annotation  and  relationships.  The  sending  system 
places  its  part  model  into  the  IGES  entities,  and  the  receiving 
system  extracts  the  information  to  construct  its  part  model. 
Incomplete  data  exchange  results  when  either  system  fails  to 
adequately  transform  its  native  representation  to  or  from  the 
IGES  representation.  Since  all  systems  do  not,  or  cannot, 
support  all  IGES  entities,  narrower  s\ibsets  of  entity  types  are 
selected  to  support  common  data  exchange  requirements. 


4.5  EDIF  Product  Data  Exchange.  «  To  Be  Developed  » 

4.6  VHSIC  Product  Data  Exchange.  «  To  Be  Developed  » 
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5 . 0  DETAILED  REQUIREMENTS 


5.1  Exchange  of  IGES  Product  Data.  VThere  IGES  io  used  for 
product  data  exchange,  the  detailed  requirements  of  MIL-SPEC-nnn 
shall  be  used. 

5.2  Application  Subsets.  Each  engineering  application 

has  different  requirements  for  the  data  needed  to  describe  the 
product  model.  The  first  step  in  specifying  how  an  applications 
area  can  exchange  its  product  description  as  a  digital  dataset  is 
to  carefully  define  the  information  content  to  be  transmitted. 

The  second  step  is  to  specify  how  this  information  is  mapped 
unambiguously  into  each  IGES  entity.  The  resulting  list  of  IGES 
entities  and  their  meaning  in  the  context  of  the  application  forms 
what  is  termed  the  application  subset.  An  application  subset  of 
IGES  can  then  be  defined  as  a  set  of  specific  IGES  entity  types 
which  are  used  to  completely  and  unambiguously  represent  the 
information  requirements  of  the  product  for  the  named  application 
purpose. 


5.2.1  Restrictive  Nature  of  Subsets.  For  each  application 
subset,  no  IGES  entities  shall  be  used  which  are  not  enumerated  in 
the  defined  sxibset.  Systems  generating  IGES  data  conforming  to 
these  subsets  shall  not  generate  IGES  entities  outside  the 
specified  subset.  Systems  designed  to  interpret  these  subsets 
shall  be  able  to  handle  all  IGES  entities  within  the  specified 
subset . 


5.2.2  Requirements  on  Subsets.  All  IGES  application  subsets 
shall  comply  with  the  IGES  Specification  for  entity  syntax  and 
file  structure.  They  shall  also  comply  with  the  detailed 
specifications  of  MIL-SPEC-nnnn.  IGES  files  are  composed  of  five 
sections.  Start,  Global,  Directory  Entry,  Parameter  Data  and 
Terminate.  This  standard  places  additional  requirements  on  these 
sections . 


5. 2. 2.1  Start  Section.  The  following  information  shall  be 
given  in  the  Start  Section  of  the  file: 

a.  Statement  of  conformance  to  the  relevant  application 
subset  and  the  revision  date  of  the  subset. 

b.  The  identification  of  the  product  being  described. 

c.  Date  the  file  was  prepared. 

d.  Performing  organization,  date  and  contract  number. 

e.  Data  organization  method  used  with  contents  of  each  level. 
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5. 2. 2. 2  Global  Section.  The  following  fields  in  the  Global 
Section  are  required  and  shall  not  be  defaulted: 


Field 

1 

2 

3-11 

12 

13 

14 

15 

16 
17 

18-22 

23 

24 


Value 


1.0 

1-11 


1-4 

0-7 


Required 

Y 

Y 

Y 

N  Default  to  Field  3 

Y 

Y 

Y 

Y 
N 

Y 

Y 
N 


5. 2. 2. 3  Directory  Entry  Section.  The  following  capabilities 
shall  be  provided  and  shall  be  supported  for  all  entities: 

a.  The  Level  Number  Field.  All  values  shall  be  positive  except 
where  necessary  to  maintain  the  truest  meaning  of  the 
referenced  entity. 

b.  The  Logical  and  Physical  Subordinate  Entity  Switch. 

c.  The  Entity  Use  Flag. 

d.  The  Hierarchical  Status  Flag. 

e.  The  Line  Weight  Number. 

f.  The  Color  Number. 


5. 2. 2. 5  Parameter  Data  Section.  No  restrictions  of  a  general 
nature  are  placed  on  the  parameters  in  the  Parameter  Data  Section. 

5. 2. 2. 6  Terminate  Section.  No  restrictions  of  a  general 
nature  are  placed  on  the  parameters  in  the  Terminate  Section. 

5.3  Testing  Requirements.  Start,  Global,  Directory  Entry, 
Parameter  Data  and  Terminate  Sections  shall  each  be  analyzed  for 
conformance  to  the  IGES  Specification  with  an  appropriate  software 
utility.  The  Start  Section  and  the  Global  Section  shall  be 
printed  out  and  checked  visually  with  requirements  of  the 
applicable  MIL-SPEC-nnn  application  subset. 
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5.4  EDIF  Product  Data  Exchange.  «  To  Be  Developed  » 

5.5  VHSIC  Product  Data  Exchange.  <<  To  Be  Developed  » 
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DRAFT  MILITARY  SPECIFICATION  FOR  DOD  ADOPTION 


APPENDIX  C 


NOTE:  This  draft,  dated  27  February  87  prepared  by  Div  732 

National  Bureau  of  Standards,  has  not  been  approved  and  is 
subject  to  modification.  DO  NOT  USE  FOR  ACQUISITION  PURPOSES. 
Project  NBS  CALS  Product  Data. 


MILITARY  SPECIFICATION 
IGES  APPLICATION  SUBSETS 


Beneficial  comments  (  recommendations,  additions  deletions) 
and  any  pertinent  data  which  may  be  of  use  in  improving  this 
doc\iment  should  be  addressed  to  Bradford  Smith,  Bldg.  220, 

Rm  A353,  Bureau  of  Standards,  Gaithersburg,  MD  20899  by 
using  the  self-addressed  Standardization  Document 
Improvement  Proposal  (DD  Form  1426)  appearing  at  the  end 
of  this  document  or  by  letter. 


DISTRIBUTION  STATEMENT  A.  Approved  for  public  release; 

distribution  is  unlimited. 
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The  Appendix  C  submitted  in  February  1987  was 
accepted  as  the  base  document  for  a  new 
military  specification.  The  approved  document, 

MIL  -  D  -  28000,  was  approved  on  22  December  1987. 
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